Wayland: Mouse is locked to VM guest (only KDE, Gnome unaffected)

[polarathene]

Describe the bug

This seems to be as described in #528 (comment)

I'm running gnome 40.1 with Wayland. The mouse stays locked to the VM and I have to use CTRL+ALT to break out of the VM.

But the linked comment mention of kernel config (which resolved the reporters problem) is not the cause, the kernel already has that config:

CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_VMMOUSE=y

This only affects KDE on Wayland. Gnome on Wayland is unaffected.

---

VMware Workstation 16 Player - 16.2.3 build-19376536

• I have verified on guest VMs with EndeavourOS, Fedora 36 and openSUSE Tumbleweed.
• I assume the host has nothing to do with it as guests using Gnome on Wayland work correctly? (Gnome 42.2, same common package versions as listed)

Host - Manjaro KDE:

Plasma: 5.24.5
Frameworks: 5.94
Qt: 5.15.4
Kernel 5.17.9
xorg: 21.1.3, xwayland 22.1.1, mesa 22.0.4, nvidia 510.73.05
open-vm-tools: 12.0.0
vmware-workstation: 16.2.3

VM Guest - EndeavourOS KDE:

Plasma: 5.25.2
Frameworks: 5.95
Qt: 5.15.5
Kernel: 5.18.9
xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.5
systemd: 251.2

VM Guest - Fedora 36 KDE:

Plasma: 5.25.2
Frameworks: 5.94
Qt: 5.15.3
Kernel 5.18.9
xorg: 1.20.14, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.5
systemd: 250.7

VM Guest - openSUSE Tumbleweed 20220704 KDE:

Plasma: 5.25.2
Frameworks: 5.95
Qt: 5.15.5
Kernel 5.18.6
xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.0
systemd: 250.6

Reproduction steps

1. Install two VMware guests (_with one of these distro: EndeavourOS, Fedora 36, or openSUSE TW_), one for KDE, one for Gnome. Host is X11 (_Manjaro KDE in my case_).
2. In the Wayland sessions, observe that Gnome maintains seamless mouse movement between host OS and guest window. KDE does not (_only when the guest is in an X11 session_). _An alternative `wlroots` based Wayland compositor `kwinft` also experiences this limitation with guests using a Wayland session._

Expected behavior

• KDE should be able to match the behaviour of seamless mouse movement like in X11, as Gnome Wayland appears capable of it.
• Otherwise, clarification for what might cause KDE Wayland to lack support (Wayland protocol implementation?)

Additional context

It's possible that both distros have some difference in packaging/configuration for their Gnome spins that is lacking from KDE that only affects Wayland sessions?

[rprabhud]

Thanks for reporting your problem. We have informed the product team responsible for this issue and opened an internal bug. As this issue is not related to open-vm-tools, please use VMTN (https://communities.vmware.com/) or VMware Support service for further updates on this issue or other product issues unrelated to open-vm-tools.

[polarathene]

As this issue is not related to open-vm-tools

I think clipboard sync is also related to this problem? I haven't tried to test other features.

Gnome supports that as well on Wayland. Is that related to open-vm-tools, or should I also defer to VMTN?

[polarathene]

On an EndeavourOS KDE host (X11 with nvidia 535 driver series) and guest (Wayland + SVGA3D), both fully updated:

VMware Workstation 17 Player - 17.0.2 build-21581411

Plasma: 5.27.5
Frameworks: 5.107.0
Qt: 5.15.10
Kernel: 6.3.8
xorg: 21.1.8, xwayland: 23.1.2, mesa 23.1.2, vmwgfx 2.20.0
open-vm-tools: 12.2.5
systemd: 253.5

---

No clue where the issue was, but it seems to be resolved as I cannot seem to reproduce the bug.

Possible guess (resolved, not a cause)

UPDATE: Disregard. I originally tried disabling the vmtoolsd.service and also kernel boot param module_blacklist=vmwgfx, but instead of blacklisting completely, it turns out dracut was now adding the module into early boot, and could be blacklisted with rd.driver.blacklist=vmwgfx as the kernel boot param instead. Now the resolution wouldn't update when resizing the vmplayer guest window. Mouse is still not locked despite that, thus this isn't valid.

I tried many restarts of the guest but could not trigger an issue I experienced recently with X11 (linking solution) with the vmwgfx kernel module not being loaded early enough before vmtoolsd is started.

That would prevent the VM guest window resolution auto-resizing to the new window size, and presumably may have been related to this bug report behaviour if experienced on Wayland. Blacklisting the kernel module at boot prevents access to a graphical session, so it's a bit tricky to try reproduce to verify.

---

EDIT: This issue is still present with kwinft 5.27.0. That alternative compositor uses wlroots and several other dependencies for display management, but at least narrows the fix down to something in kwin / kscreen that has not been resolved in the equivalent kwinft packages.

[polarathene]

I think clipboard sync is also related to this problem?

Apps running via XWayland still works with clipboard sync. Native Wayland does not work, and is possibly due to something different between Gnome and KDE.

vmware-user-suid-wrapper that is related to the functionality, relies on GTK which implicitly enables at-spi-dbus-bus.service via DBUS, this launches the service with --gnome-session which may hint at some Gnome specific integration. (EDIT: Nope, see below)

---

Gnome 44.2

Part of related investigation in: #670 (comment)

I've used the an approach I've detailed for a spi.service but without the --gnome-session. On a Wayland Gnome session this still enables full copy/paste that KDE Plasma lacks (only supports XWayland apps).

Verified with xorg-xeyes package (xeyes command) and the Wayland native terminal vs Firefox (runs via XWayland presently when launched). Only Gnome can copy text from guest to terminal to host OS clipboard (host KDE Plasma).

Plasma 5.27

Worth noting is that this also affects clipboard sync from the host system. It only sync'd the clipboard copy from host to the guest when I had an X11 app like Firefox focused on the guest during my copy. Which implies it is similar to how xeyes is only actively updating when the cursor is over an X11 / XWayland app window.