SUMMARY I have a video of the issue right here: https://www.youtube.com/watch?v=3tyqU1nFuvY&feature=youtu.be I'm using a a VMWare virtual machine with the latest KDE Neon unstable, and I noticed the cursor "hit box" is offset. Like, i'm using the Wayland session right now, and if I try to select this line the cursor actually selects the line above it. I tested the same virtual machine in a Gnome Wayland session and it works normally, including QT apps. The bug doesn't seem to affect Plasma Shell as much (I can still see some weird cursor changes on Kickoff when hovering over text fields and the profile picture, but interacting with the taskbar and icons on the desktop seems fine). The bug is especially visible on Discover and web browsers. It's also visible when trying to resize windows. I don't know if this happens on real hardware as I don't have Linux installed on my machine. STEPS TO REPRODUCE 1. Enter a Plasma Wayland Session using VMWare (I'm using VMWare open tools package for drivers) 2. Interact with programs, resize windows and hover mouse cursor over elements. OBSERVED RESULT Cursor doesn't click to where it's pointing. Moving it over elements like buttons and text boxes causes it to change and jump around. EXPECTED RESULT Cursor should actually click to where it's pointing and not jump around when hovering over elements like buttons and text boxes. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Kernel Version: 5.4.0-48-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i5-9400F CPU @ 2.90GHz Memory: 3.8 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; ADDITIONAL INFORMATION VMWare open-tools package installed for drivers. Gnome Wayland works fine on the same virtual machine.
Can you please run kwin with KWIN_FORCE_SW_CURSOR=1 and check whether the cursor position is still off?
(In reply to Vlad Zahorodnii from comment #1) > Can you please run kwin with KWIN_FORCE_SW_CURSOR=1 and check whether the > cursor position is still off? Yes, forcing KWIN_FORCE_SW_CURSOR=1 does fix the issue. The shadows under the cursor are a bit buggy sometimes but the cursor position is fixed when using it.
We currently miss a proper way to support VMs cursors.
Aren't VM cursors just regular cursor planes?
Git commit 3b8e489b6f384239cbe30a2dccc064a4ecc2c9bd by Vlad Zahorodnii. Committed on 16/10/2020 at 17:03. Pushed by vladz into branch 'master'. platforms/drm: Compute correct cursor transform matrix Currently, when the DRM platform uses cursor planes, the cursor on a rotated output may be cropped because the math behind the current cursor transform matrix is off. In order to fix the cropping issue, this change replaces the current cursor transform matrix with the core part of the surface-to-buffer matrix, which was written against the wl_output spec. Related: bug 427605 M +39 -11 plugins/platforms/drm/drm_output.cpp M +0 -1 plugins/platforms/drm/drm_output.h https://invent.kde.org/plasma/kwin/commit/3b8e489b6f384239cbe30a2dccc064a4ecc2c9bd
Git commit 1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f by Vlad Zahorodnii. Committed on 16/10/2020 at 17:06. Pushed by vladz into branch 'Plasma/5.20'. platforms/drm: Compute correct cursor transform matrix Currently, when the DRM platform uses cursor planes, the cursor on a rotated output may be cropped because the math behind the current cursor transform matrix is off. In order to fix the cropping issue, this change replaces the current cursor transform matrix with the core part of the surface-to-buffer matrix, which was written against the wl_output spec. Related: bug 427605 M +39 -11 plugins/platforms/drm/drm_output.cpp M +0 -1 plugins/platforms/drm/drm_output.h https://invent.kde.org/plasma/kwin/commit/1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f
(In reply to Vlad Zahorodnii from comment #6) > Git commit 1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f by Vlad Zahorodnii. > Committed on 16/10/2020 at 17:06. > Pushed by vladz into branch 'Plasma/5.20'. > > platforms/drm: Compute correct cursor transform matrix > > Currently, when the DRM platform uses cursor planes, the cursor on > a rotated output may be cropped because the math behind the current > cursor transform matrix is off. > > In order to fix the cropping issue, this change replaces the current > cursor transform matrix with the core part of the surface-to-buffer > matrix, which was written against the wl_output spec. > Related: bug 427605 > > M +39 -11 plugins/platforms/drm/drm_output.cpp > M +0 -1 plugins/platforms/drm/drm_output.h > > https://invent.kde.org/plasma/kwin/commit/ > 1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f Hi, how can I test these patches? Is it only available on the latest stable Plasma 5.20? Because I'm testing the latest fully updated Neon >Unstable Edition< and the bug still persists. Thanks.
(In reply to guimarcalsilva from comment #7) > (In reply to Vlad Zahorodnii from comment #6) > > Git commit 1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f by Vlad Zahorodnii. > > Committed on 16/10/2020 at 17:06. > > Pushed by vladz into branch 'Plasma/5.20'. > > > > platforms/drm: Compute correct cursor transform matrix > > > > Currently, when the DRM platform uses cursor planes, the cursor on > > a rotated output may be cropped because the math behind the current > > cursor transform matrix is off. > > > > In order to fix the cropping issue, this change replaces the current > > cursor transform matrix with the core part of the surface-to-buffer > > matrix, which was written against the wl_output spec. > > Related: bug 427605 > > > > M +39 -11 plugins/platforms/drm/drm_output.cpp > > M +0 -1 plugins/platforms/drm/drm_output.h > > > > https://invent.kde.org/plasma/kwin/commit/ > > 1fd9ae618aaf8b9fcd5b644fa3039ec782d6355f > > Hi, how can I test these patches? Is it only available on the latest stable > Plasma 5.20? Because I'm testing the latest fully updated Neon >Unstable > Edition< and the bug still persists. Thanks. This fix was part of plasma 5.20.1, but it did not fix this bug. The commit just CC-ed the bug "CCBUG: 427060" which means it might related or of interest for this bug fix.
*** Bug 423849 has been marked as a duplicate of this bug. ***
(In reply to guimarcalsilva from comment #0) > ADDITIONAL INFORMATION > > VMWare open-tools package installed for drivers. Are VMWare open-tools essential for the problem? I couldn't reproduce on VirtualBox with Guest Additions installed.
I can reproduce in VirtualBox 6.1.16_Ubuntu r140961. Guest Additions of same version installed in the KDE Neon User Edition VM. Guest using Wayland; KDE Neon host using X11. VMSVGA graphics with 3D acceleration enabled.
(In reply to Andrey from comment #10) > (In reply to guimarcalsilva from comment #0) > > ADDITIONAL INFORMATION > > > > VMWare open-tools package installed for drivers. > Are VMWare open-tools essential for the problem? I couldn't reproduce on > VirtualBox with Guest Additions installed. Sorry, I don't have access to the virtual machine right now, but I was indeed using open-tools instead of guest additions. I don't know if it's reproducible with guest additions. I gotta add I was using Windows 10 as the guest.
(In reply to guimarcalsilva from comment #12) > (In reply to Andrey from comment #10) > > (In reply to guimarcalsilva from comment #0) > > > ADDITIONAL INFORMATION > > > > > > VMWare open-tools package installed for drivers. > > Are VMWare open-tools essential for the problem? I couldn't reproduce on > > VirtualBox with Guest Additions installed. > > Sorry, I don't have access to the virtual machine right now, but I was > indeed using open-tools instead of guest additions. I don't know if it's > reproducible with guest additions. > > I gotta add I was using Windows 10 as the guest. I mean, Windows 10 as the host. Also, I couldn't get guest additions to work, that's why I was using open-tools. I'll try to get it to work and see if I can reproduce the issue. If there's any kind of logs or other useful information I can provide please let me know.
OK, can see it now on Virtual Box. No Guest additions are needed.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1212
Please note the fix wont work for NVidia
We got some issues after the fix we can't reproduce currently: https://invent.kde.org/plasma/kwin/-/merge_requests/1212#note_286461 So the request would be to test it and report any problems one could find. Thanks.
*** Bug 443357 has been marked as a duplicate of this bug. ***
I can still see the glitchy cursor in VirtualBox with KDE Neon guest (Plasma 5.23.4, Wayland). Host has amdgpu graphics. Someone else has similar issues in Wayland too: https://www.reddit.com/r/kde/comments/r1csff/glitchy_cursor_on_wayland/ , I'm not sure if it was in VM or not
I can't test on amdgpu graphics. Anyone else please confirm.
Fedora 35 running Plasma 5.24.2/Frameworks 5.91.0/QT 5.15.2 Wayland on VMWare Workstation Player 16.2. I'm still experiencing this bug.
Quoting Zammundaa https://www.reddit.com/r/kde/comments/tbr5ey/comment/i0a7ki0/?utm_source=share&utm_medium=web2x&context=3 ``` VMs pretend they support atomic modesetting, when they don't actually support it properly.[...] You can work around it by using the environment variable KWIN_DRM_NO_AMS=1, which forces KWin to use the legacy driver API that VMs actually handle properly (or to be really precise, less badly) ```
*** Bug 449331 has been marked as a duplicate of this bug. ***
(In reply to Méven Car from comment #22) > Quoting Zammundaa > https://www.reddit.com/r/kde/comments/tbr5ey/comment/i0a7ki0/ > ?utm_source=share&utm_medium=web2x&context=3 > > ``` > VMs pretend they support atomic modesetting, when they don't actually > support it properly.[...] > > You can work around it by using the environment variable KWIN_DRM_NO_AMS=1, > which forces KWin to use the legacy driver API that VMs actually handle > properly (or to be really precise, less badly) > ``` This comment blames the wrong component(s) in the stack, as it's actually the kernel which does not support specifying a cursor hotspot if AMS is used. I suggest to have KWin prefer legacy modesetting in VMs for that reason, like other compositors already do. When the necessary kernel changes are implemented (which I unfortunately don't see any sign of), this could be changed again in the future.
The VM drivers or VMs themselves are at fault, they mis-use the API - the drm plane position set by the compositor is ignored, and they pretend that the "cursor plane" must always be used for cursors. Both things are wrong. Working around driver bugs is a thing that I'd *really* like to avoid unless it's completely session-breaking, as otherwise they never get fixed. So, before we do anything at all in KWin I'd like to at the very least have a bug report upstream that makes sure that the bug gets tracked in the proper place, ideally with a comment from the relevant kernel people on what they want to do about it. And if they don't want to do anything about it in the near future then the best approach would be if they'd stop pretending like they support AMS, when they really don't do it properly.
(In reply to Zamundaaa from comment #25) > The VM drivers or VMs themselves are at fault, they mis-use the API - the > drm plane position set by the compositor is ignored, and they pretend that > the "cursor plane" must always be used for cursors. Both things are wrong. > > Working around driver bugs is a thing that I'd *really* like to avoid unless > it's completely session-breaking, as otherwise they never get fixed. > > So, before we do anything at all in KWin I'd like to at the very least have > a bug report upstream that makes sure that the bug gets tracked in the > proper place, ideally with a comment from the relevant kernel people on what > they want to do about it. And if they don't want to do anything about it in > the near future then the best approach would be if they'd stop pretending > like they support AMS, when they really don't do it properly. If you disagree with the design that's used by the kernel and VM stack, please start discussion about that yourself.
Sounds like we're in that awkward situation where we decided to depend on something lower in the stack always working properly, and it doesn't, so now we're left with a set of bad options: 1. Stop depending on the thing 2. Fix the thing to work properly 3. Put in local workarounds for the broken parts of the thing Note that there is no option for "leave it knowingly broken because it's upstream's job to fix it" :)
From my perspective it seems like this got fixed, then came back. In Fedora 35 we were suffering from this; I backported https://github.com/KDE/kwin/commit/998bbf4eba724a9b94a5bae62182456b85b11383#diff-034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 , and that fixed it. Now people are reporting in F36 Beta that it's back again. What changed upstream? Was that fix reverted or lost?
(In reply to Adam Williamson from comment #28) > From my perspective it seems like this got fixed, then came back. In Fedora > 35 we were suffering from this; I backported > https://github.com/KDE/kwin/commit/ > 998bbf4eba724a9b94a5bae62182456b85b11383#diff- > 034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 , and that > fixed it. Now people are reporting in F36 Beta that it's back again. > > What changed upstream? Was that fix reverted or lost? KWin now uses AMS in VMs, without drmModeSetCursor2.
(In reply to Adam Williamson from comment #28) > From my perspective it seems like this got fixed, then came back. In Fedora > 35 we were suffering from this; I backported > https://github.com/KDE/kwin/commit/ > 998bbf4eba724a9b94a5bae62182456b85b11383#diff- > 034885748897f413c645e3efd125d7c0db9a8454d580f6093e40c885d974c818 , and that > fixed it. Now people are reporting in F36 Beta that it's back again. > > What changed upstream? Was that fix reverted or lost? Just opened a new RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2063969
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2163
Git commit 4a7007cd935a864847962106f170d2428943f025 by Xaver Hugl. Committed on 21/03/2022 at 20:28. Pushed by zamundaaa into branch 'master'. backends/drm: fall back to legacy mode in virtual machines Virtual machines aren't properly supporting atomic mode setting yet, which causes the cursor to be offset, and will cause more issues with overlay planes. In order to prevent that from impacting users, fall back to legacy, unless KWIN_DRM_NO_AMS is set. FIXED-IN: 5.24.4 M +8 -4 src/backends/drm/drm_gpu.cpp M +1 -0 src/backends/drm/drm_gpu.h https://invent.kde.org/plasma/kwin/commit/4a7007cd935a864847962106f170d2428943f025
Git commit 9f2ed15be073d3c4cc3e133acecf8d586322b2bf by Xaver Hugl. Committed on 21/03/2022 at 21:06. Pushed by zamundaaa into branch 'Plasma/5.24'. backends/drm: fall back to legacy mode in virtual machines Virtual machines aren't properly supporting atomic mode setting yet, which causes the cursor to be offset, and will cause more issues with overlay planes. In order to prevent that from impacting users, fall back to legacy, unless KWIN_DRM_NO_AMS is set. FIXED-IN: 5.24.4 (cherry picked from commit 4a7007cd935a864847962106f170d2428943f025) M +8 -4 src/backends/drm/drm_gpu.cpp M +1 -0 src/backends/drm/drm_gpu.h https://invent.kde.org/plasma/kwin/commit/9f2ed15be073d3c4cc3e133acecf8d586322b2bf
I am afraid this bug is occurring again, at least in my setup. openSUSE Tumbleweed / MicroOS VM Guest, Plasma 5.27.1, Linux kernel 6.2 on Windows 11 host with AMD graphics. I was originally affected by this bug also last year so I remember it has been fixed for a while but now it has come back. Pretty sure this started happening only after the update from kernel 6.1 -> 6.2.
Please attach the output of > drm_info and > journalctl --user-unit plasma-kwin_wayland --boot 0 from in the VM
(In reply to Michael SB from comment #34) > I am afraid this bug is occurring again, at least in my setup. > > openSUSE Tumbleweed / MicroOS VM Guest, Plasma 5.27.1, Linux kernel 6.2 on > Windows 11 host with AMD graphics. > > I was originally affected by this bug also last year so I remember it has > been fixed for a while but now it has come back. Pretty sure this started > happening only after the update from kernel 6.1 -> 6.2. FTR, it works fine here with virt-manager. Both VM host and guest use kernel 6.2 and Plasma 5.27.2 with Wayland. The cursor is handled through virtio-gpu and spice though, probably different from what you use on a Windows host.
Created attachment 157112 [details] drm_info and journalctl logs in a clean Plasma 5.27.2 Wayland session
(In reply to Michael SB from comment #37) > Created attachment 157112 [details] > drm_info and journalctl logs in a clean Plasma 5.27.2 Wayland session Perhaps it is noteworthy to mention that besides the cursor being offset, it is also quite "jumpy", especially around window borders, and it tends to get "stuck" until hovering another element like a link that causes it to change. I tried to demonstrate it briefly in this video https://imgur.com/a/xJMWXgj
According to the logs, kwin is correctly falling back to legacy to avoid this problem. As it works on different VMs I'm relatively confident you're experiencing a problem on the driver or VM side. If it worked correctly with earlier kernel versions, the problem will be in there. A bisect would be useful for finding out what causes it
I also see it again... Neon Unstable (as a KVM Guest) Plasma: 5.27.80 Frameworks: 5.104.0 Qt: 5.15.8 Kernel: 5.19.0-35-generic (64-bit) Wayland / QXL video It does not seem a consistent offset - for some buttons I have to click a little to the right, others a little underneath, some things I don't seem able to click. A "working system" rather than a clean install. All OK if I change to Virtio. All OK if I log in with X11
(In reply to tagwerk19 from comment #40) > I also see it again... > > Neon Unstable (as a KVM Guest) > Plasma: 5.27.80 > Frameworks: 5.104.0 > Qt: 5.15.8 > Kernel: 5.19.0-35-generic (64-bit) > Wayland / QXL video > > It does not seem a consistent offset - for some buttons I have to click a > little to the right, others a little underneath, some things I don't seem > able to click. > > A "working system" rather than a clean install. > > All OK if I change to Virtio. All OK if I log in with X11 Weird, I just tested on latest daily image of Kubuntu Lunar and this issue is not happening in Plasma Wayland guest on VMWare, despite Lunar already using kernel 6.1.0. I thought it was caused by kernel 6.0 branch but it seems I was wrong. But the fact that it's happening in Neon (which is also Ubuntu based) but not in Kubuntu, yet it happens in Tumbleweed also, leaves me perplexed. I've resorted to using Kubuntu for now until I can have more time to troubleshoot (as x11 session has become very 'choppy' compared to Wayland on VMWare guests).
Just did an update on Kubuntu Lunar 23.04 and right after a reboot the cursor offset issue on Wayland has appeared (for the first time in this guest VM). Most notably, there was an update to kernel 6.2.0-18 Here's a complete list of the packages that were updated: 2023-03-23 10:57:27 status installed gcc-13-base:amd64 13-20230320-1ubuntu1 2023-03-23 10:57:28 status installed libstdc++6:amd64 13-20230320-1ubuntu1 2023-03-23 10:57:28 status installed libgcc-s1:amd64 13-20230320-1ubuntu1 2023-03-23 10:57:53 status installed printer-driver-foo2zjs-common:all 20200505dfsg0-2ubuntu3 2023-03-23 10:58:17 status installed linux-firmware:all 20230323.gitbcdcfbcf-0ubuntu1 2023-03-23 10:58:20 status installed linux-modules-6.2.0-18-generic:amd64 6.2.0-18.18 2023-03-23 10:58:20 status installed linux-modules-extra-6.2.0-18-generic:amd64 6.2.0-18.18 2023-03-23 10:58:20 status installed libobjc4:amd64 13-20230320-1ubuntu1 2023-03-23 10:58:20 status installed linux-headers-6.2.0-18:all 6.2.0-18.18 2023-03-23 10:58:21 status installed samba-common:all 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:21 status installed libgomp1:amd64 13-20230320-1ubuntu1 2023-03-23 10:58:21 status installed libwbclient0:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:21 status installed printer-driver-foo2zjs:amd64 20200505dfsg0-2ubuntu3 2023-03-23 10:58:21 status installed libgfortran5:amd64 13-20230320-1ubuntu1 2023-03-23 10:58:21 status installed printer-driver-splix:amd64 2.0.0+svn315-7fakesync1build4 2023-03-23 10:58:21 status installed brave-browser:amd64 1.49.128 2023-03-23 10:58:22 status installed linux-image-6.2.0-18-generic:amd64 6.2.0-18.18 2023-03-23 10:58:24 status installed ubuntu-advantage-tools:amd64 27.14~23.04.1 2023-03-23 10:58:24 status installed libldb2:amd64 2:2.6.1+samba4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:24 status installed linux-image-generic:amd64 6.2.0.18.18 2023-03-23 10:58:24 status installed samba-libs:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:24 status installed linux-headers-6.2.0-18-generic:amd64 6.2.0-18.18 2023-03-23 10:58:24 status installed python3-ldb:amd64 2:2.6.1+samba4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:24 status installed libsmbclient:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:24 status installed smbclient:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:24 status installed samba-dsdb-modules:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:25 status installed python3-samba:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:25 status installed linux-headers-generic:amd64 6.2.0.18.18 2023-03-23 10:58:25 status installed samba-common-bin:amd64 2:4.17.5+dfsg-2ubuntu3 2023-03-23 10:58:25 status installed linux-generic:amd64 6.2.0.18.18 2023-03-23 10:58:25 status installed libc-bin:amd64 2.37-0ubuntu1 2023-03-23 10:58:26 status installed man-db:amd64 2.11.2-1 2023-03-23 10:58:26 status installed mailcap:all 3.70+nmu1ubuntu1 2023-03-23 10:58:26 status installed desktop-file-utils:amd64 0.26-1ubuntu5 2023-03-23 10:58:29 status installed cups:amd64 2.4.2-1ubuntu4 2023-03-23 10:58:50 status installed linux-image-6.2.0-18-generic:amd64 6.2.0-18.18
I'll add another anecdote that I'm seeing this issue as well on Fedora 37 under VMWare Workstation 16 on a Windows host. Recently I got a kernel upgrade from a 6.1 version to 6.2 and I started seeing the issue with that update. If I boot the system using the previous 6.1 kernel using Grub2, then the problem goes away and everything works fine; I only see the problem using the 6.2 kernel. Not Working System Info: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × Intel® Xeon® CPU E5-2630 v4 @ 2.20GHz Memory: 62.8 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; Manufacturer: VMware, Inc. Product Name: VMware Virtual Platform System Version: None Working System Info: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.1.18-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × Intel® Xeon® CPU E5-2630 v4 @ 2.20GHz Memory: 62.8 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; Manufacturer: VMware, Inc. Product Name: VMware Virtual Platform System Version: None If there's any other information I can provide I'd be happy to do so.
I had a similar issue today in the wayland session with virtio: There was no offset at the origin (top left), but the X and Y offset increased towards the opposite edges, as if there was some broken scale factor involved. Resizing the VM window triggered a resolution change and the issue disappeared.
(In reply to Fabian Vogt from comment #44) > I had a similar issue today in the wayland session with virtio: There was no > offset at the origin (top left), but the X and Y offset increased towards > the opposite edges, as if there was some broken scale factor involved. > > Resizing the VM window triggered a resolution change and the issue > disappeared. I tried this workaround using my setup, which is fairly different to yours, and it did not work there.
same issue fresh arch install vmware workstation player 17
(In reply to hallucynogenyc from comment #46) > same issue > > fresh arch install > vmware workstation player 17 Yeah this bug on Plasma Wayland has been persisting for a long time across distros, while Plasma x11 session behaves quite sluggish on VMWare Player (for example resizing windows), which unfortunately has rendered KDE unusable for me as guest on my work Windows PC.
(In reply to Michael SB from comment #47) > (In reply to hallucynogenyc from comment #46) > > same issue > > > > fresh arch install > > vmware workstation player 17 > > Yeah this bug on Plasma Wayland has been persisting for a long time across > distros, while Plasma x11 session behaves quite sluggish on VMWare Player > (for example resizing windows), which unfortunately has rendered KDE > unusable for me as guest on my work Windows PC. I'm happy to inform that on Plasma 6 Beta 1, the cursor offset on Plasma Wayland seems to be gone! Tried with openSUSE Krypton guest VM running on Windows 11 Host under VMWare Workstation 17 Player. System details below: Operating System: openSUSE Tumbleweed 20231202 KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 Kernel Version: 6.6.3-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 5.8 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; Manufacturer: VMware, Inc. Product Name: VMware Virtual Platform System Version: None
*** Bug 478614 has been marked as a duplicate of this bug. ***
(In reply to guimarcalsilva from comment #49) > *** Bug 478614 has been marked as a duplicate of this bug. *** There's a brand new duplicate of this bug report on Plasma 6. I'll reopen it because it seems it might not be fixed for everyone.
(In reply to guimarcalsilva from comment #50) > (In reply to guimarcalsilva from comment #49) > > *** Bug 478614 has been marked as a duplicate of this bug. *** > > There's a brand new duplicate of this bug report on Plasma 6. I'll reopen it > because it seems it might not be fixed for everyone. The new one focus on QEMU, this bug reported on VMWare. We'd need to test with virtualbox as well.
It's most helpful to just focus on the new bug report, so let's close this and un-dupe the new one.
Seems to be fixed in plasma-wayland but not in plasma-x11