Bug 427060

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

Unfixed on
 KDE Plasma: 5.27.11
KDE frameworks:  5.115.0
QT 5.15.13
Kernel: 6.8.0-31-generic
Wayland
Ubuntu 24.04

It's a different issue that was later fixed in Plasma 6. In general, please open new bug reports rather than re-opening old ones. Thanks.

Bug is not fixed!

Host: Intel i7 11850H
OS: Win 11 22H2
VMware Player: 17.5.0
GPU: NVIDIA T1200 (anyways, happens with hardware acceleration enabled/disabled)

Fresh install:
Guest: Kubuntu 23.10
KDE: 5.27.8
KDE Framework: 5.11.0
QT Version: 5.15.10
Kernel: 6.5.0-28

Is there any other workaround/fix other than using environment variable KWIN_FORCE_SW_CURSOR=1? That will fix it, but also disables automatic realease/grab mouse into VM.

What you're seeing is a new bug that's caused by VM GPU drivers being broken. There's a workaround in Plasma 6.0.5.