SUMMARY When run on VMware Workstation, in Wayland, and with atomic mode-setting force-enabled through export KWIN_DRM_NO_AMS=0 no cursor will be shown. STEPS TO REPRODUCE 0. VMware Workstation 17.5 1. Fedora Rawide (40) + KDE Plasma 6 beta 1 2. have KWIN_DRM_NO_AMS=0 in the environment 3. boot / login OBSERVED RESULT No cursor rendered; cursor is alive and effective though (hover / click etc). EXPECTED RESULT Rendering of cursor. Workaround: export KWIN_FORCE_SW_CURSOR=1 This is on kernel 6.7.0-rc5.
With the environment set as above, this seems to work quite well. I used Firefox to render two Youtube videos * one on 4K fullscreen resolution at FullHD * one on 3.5K fullscreen resolution at FullHD plus some more wiggling and rendering experiments and everything looked ok (on an Intel 11800H integrated GPU, which is very much not high performance). I do not know how else to stress atomic mode-setting. Cursor hotspots were perfect, in konsole, in Visual Studio Code, and in Firefox (those tended to cause problem under KDE 5.27 Wayland)
Digging through the net finds https://github.com/swaywm/sway/issues/5834 and https://github.com/swaywm/sway/issues/3814 - also no way to get hardware cursors to work on the vmwgfx driver, with the workaround also being: force software cursors. There is one report of Weston being able to successfully use hardware cursors on vmwgfx, see https://github.com/swaywm/sway/issues/5834#issuecomment-1234948941
KWin and wlroots allocate buffers to render to (with gbm) and use those for the cursor, and afaik Weston uses dumb buffers. So I'm very certain this is a driver bug. We can work around it, but please report it to the kernel too.
I am currently digging into cursors in general, have already reached out in the matter of drmCloseBufferHandle (and the TTM/GEM mess) - and have received a response from Zack Rusin of VMware / Broadcom, see https://lore.kernel.org/all/CABQX2QPkEWDhE6xAaucaFh7QWvA06xJ8bfqrmPQTKM61X-YMmQ@mail.gmail.com/ Once I understand more about "the cursor situation in KDE on top of vmwgfx", I'll follow up on this.
That response makes sense to me. While it's a weird workaround, using DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT (or maybe better, DRM_CLIENT_CAP_ATOMIC) to ensure old clients don't get changed behavior is acceptable.
As this is a driver bug, I'll close it with resolved upstream. Let me know if we still need to include a workaround though
*** Bug 479002 has been marked as a duplicate of this bug. ***