Bug 2009304 - Mouse cursor offset in GNOME VMs with Wayland (but not X11), due to use of Atomic API
Summary: Mouse cursor offset in GNOME VMs with Wayland (but not X11), due to use of At...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F35FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-09-30 10:20 UTC by Kamil Páral
Modified: 2021-10-07 23:31 UTC (History)
18 users (show)

Fixed In Version: mutter-41.0-3.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-07 23:31:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
bug demonstration on Wayland (198.71 KB, video/webm)
2021-09-30 10:25 UTC, Kamil Páral
no flags Details
bug doesn't appear on X11 (246.54 KB, video/webm)
2021-09-30 10:25 UTC, Kamil Páral
no flags Details
VM libvirt XML (5.54 KB, text/xml)
2021-09-30 10:29 UTC, Kamil Páral
no flags Details
VM libvirt XML without mouse integration (5.28 KB, text/plain)
2021-09-30 10:30 UTC, Kamil Páral
no flags Details
journal with MUTTER_DEBUG=kms (991.80 KB, text/plain)
2021-10-05 12:57 UTC, Kamil Páral
no flags Details
video of bug fixed with mutter-41.0-3 (746.78 KB, video/mp4)
2021-10-06 13:59 UTC, Geraldo Simião
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME mutter merge_requests 2040 0 None None None 2021-10-05 13:19:12 UTC
Red Hat Bugzilla 2011066 1 unspecified CLOSED Real cursor position is slightly offset from displayed position on Wayland in virtual machine (KDE case) 2022-03-15 14:40:59 UTC

Internal Links: 2006746 2011066

Description Kamil Páral 2021-09-30 10:20:48 UTC
Description of problem:
If you boot a Fedora Workstation VM (which defaults to Wayland) in virt-manager, the mouse cursor has a slight offset. I.e. when you click, the click is sent to a slightly different position (a bit more up and left) than where you see the cursor. I often see it in gnome-terminal, where I want to highlight a line and the line above gets highlighted instead. But the best showcase of this problem is the "Drawing" application ('drawing' rpm), which has a "target" cursor and you can easily see the offset. Please watch the attached videos. This is not specific to certain apps, though, it seems to affect the whole desktop, anything you run. Just in certain apps it's more noticeable.

This problem happens *only* on Wayland. If you switch to X11, there is no cursor offset (watch the second attached video).

I tried to pinpoint the issue, whether it is a compositor issue or spice issue. I found out that if I remove "Tablet" and "Channel spice" from the VM configuration, the issue disappears even when running on Wayland. However, mouse integration is disabled this way. So my suspicion is that this a problem in spice-vdagent, possibly in the mouse integration code.


Version-Release number of selected component (if applicable):
The VM guest (F35 Workstation Beta, updated):
gnome-session-wayland-session-40.1.1-2.fc35.x86_64
gnome-shell-41.0-1.fc35.x86_64
libwayland-client-1.19.0-2.fc35.x86_64
libwayland-cursor-1.19.0-2.fc35.x86_64
libwayland-egl-1.19.0-2.fc35.x86_64
libwayland-server-1.19.0-2.fc35.x86_64
qemu-audio-spice-6.1.0-5.fc35.x86_64
qemu-char-spice-6.1.0-5.fc35.x86_64
qemu-ui-spice-app-6.1.0-5.fc35.x86_64
qemu-ui-spice-core-6.1.0-5.fc35.x86_64
spice-glib-0.39-4.fc35.x86_64
spice-gtk3-0.39-4.fc35.x86_64
spice-server-0.15.0-2.fc35.x86_64
spice-vdagent-0.21.0-5.fc35.x86_64
xorg-x11-server-Xwayland-21.1.2-2.fc35.x86_64

The VM host (F35 Workstation, updated):
libvirt-7.6.0-3.fc35.x86_64
qemu-kvm-6.1.0-5.fc35.x86_64
spice-glib-0.39-4.fc35.x86_64
spice-gtk3-0.39-4.fc35.x86_64
spice-server-0.15.0-2.fc35.x86_64
virt-manager-3.2.0-4.fc35.noarch

How reproducible:
always

Steps to Reproduce:
1. create a default VM in virt-manager with F35 Workstation Beta, install it
2. boot the VM, check that you're running Wayland (gnome-control-center -> About, or `echo $XDG_SESSION_TYPE`)
3. install "drawing" package, start it
4. see that the cursor has an offset, when drawing points or lines
5. reboot the VM (due to some session related bugs at the moment)
6. select X11 session in gdm, log in
7. check that you're running X11 (gnome-control-center -> About, or `echo $XDG_SESSION_TYPE`)
8. start Drawing
9. see that the cursor doesn't have an offset, when drawing points or lines

Actual results:
cursor has an offset under Wayland

Expected results:
no offset

Additional info:
On the VM host side, running X11 or Wayland session doesn't seem to matter.
Also, I checked VMs with Fedora 33 and 34 Workstation (with Wayland), and this problem didn't occur. It seems to be new in F35.

Comment 1 Kamil Páral 2021-09-30 10:25:22 UTC
Created attachment 1827637 [details]
bug demonstration on Wayland

Comment 2 Kamil Páral 2021-09-30 10:25:37 UTC
Created attachment 1827638 [details]
bug doesn't appear on X11

Comment 3 Kamil Páral 2021-09-30 10:29:21 UTC
Created attachment 1827639 [details]
VM libvirt XML

Comment 4 Kamil Páral 2021-09-30 10:30:28 UTC
Created attachment 1827640 [details]
VM libvirt XML without mouse integration

In this VM configuration I removed the mentioned devices which enable mouse integration, and the problem no longer occurs.

Comment 5 Kamil Páral 2021-09-30 10:35:04 UTC
I'm proposing this as a F35 final blocker. There is no specific criterion, but shifted mouse cursor coordinates break many common use cases of the graphical desktop. From text selection (selecting different characters than you expect) to drawing applications to simply clicking on smaller buttons (if you position the mouse in a certain way, a neighboring button/widget might get clicked instead).

Comment 6 Adam Williamson 2021-09-30 15:37:40 UTC
As I mentioned on the other bug, Kamil, I *did* see this in earlier releases, but usually only on KDE. I hadn't seen it on Workstation till F35. With F35 host and guest I get it every time in Workstation or KDE. Not sure if it's the host or guest end that matters, when you say "I checked VMs with Fedora 33 and 34 Workstation (with Wayland)" do you mean you tested 33 and 34 in the *guest*?

Comment 7 Kamil Páral 2021-10-01 07:49:17 UTC
> when you say "I checked VMs with Fedora 33 and 34 Workstation (with Wayland)" do you mean you tested 33 and 34 in the *guest*?

Yes, I tested different VM guests (all Workstation), and only saw the problem in F35. The host was the same in all cases (F35).

Comment 8 Adam Williamson 2021-10-04 22:32:59 UTC
That's odd, I'm seeing it with an F34 guest on F35 as well. I think it's a fresh install from F34 Workstation live.

I tried removing spice-vdagent and qemu-guest-agent from the guest, but neither made any difference. So maybe this is in the core of spice, not the agent?

Comment 9 Adam Williamson 2021-10-04 23:02:00 UTC
also tried downgrading spice-server to 0.14.3 and qemu to 6.0.0; neither of those helped unless I missed restarting something between downgrades...

Comment 10 Adam Williamson 2021-10-05 00:14:18 UTC
and qemu 5.2.0 no good either. hmm.

Comment 11 František Zatloukal 2021-10-05 10:17:11 UTC
Discussed during the 2021-10-04 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made:

"In contrast to 2006746, this bug seems to happen on all boots of an F35 Workstation or KDE VM, and it causes substantial functionality issues, so we accept it as a sufficiently serious problem to constitute a violation of several graphical desktop usage requirements when running in a VM."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021-10-04/f35-blocker-review.2021-10-04-16.02.log.html

Comment 12 Hans de Goede 2021-10-05 10:44:33 UTC
This is likely a resurfacing of the mutter on Wayland cursor hotspot issue which we already hit and resolved quite some time ago. The atomic API does not allow specifying the cursor hotspot causing issues with virtual-machines which draw the cursor them-selves. The solution is to not use the atomic API (at least for the cursor) when running on say QXL graphics or a couple of other virtual GPUs.

@jadahl I believe that you fixes this the last time, can you take a look ?

This might be a mutter regression; or maybe new VMs created on F35 (the host is F35 too) use a new type of virtual GPU which needs to be added to the list of virtual GPUs mutter checks for ?

Comment 13 Hans de Goede 2021-10-05 10:55:37 UTC
The attached libvirt xml description of the VM has this:

<video>
<model type="virtio" heads="1" primary="yes"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

Maybe the use of virtio instead of qxl is new(ish) (I thought it was the default for a while already but not sure) and this is missing from the list of virtual GPUs which mutter treats specially to avoid the hotspot issue?

Comment 14 Kamil Páral 2021-10-05 11:09:58 UTC
Hans, switching from virtio GPU to qxl indeed fixes the problem, the cursor offset is no longer present.

Comment 15 Jonas Ådahl 2021-10-05 11:32:01 UTC
A log output of running with MUTTER_DEBUG=kms in the environment would help.

Comment 17 Kamil Páral 2021-10-05 12:57:53 UTC
Created attachment 1829408 [details]
journal with MUTTER_DEBUG=kms

(In reply to Jonas Ådahl from comment #15)
> A log output of running with MUTTER_DEBUG=kms in the environment would help.

Attached.

Comment 18 Jonas Ådahl 2021-10-05 13:01:22 UTC
(In reply to Kamil Páral from comment #17)
> Created attachment 1829408 [details]
> journal with MUTTER_DEBUG=kms
> 
> (In reply to Jonas Ådahl from comment #15)
> > A log output of running with MUTTER_DEBUG=kms in the environment would help.
> 
> Attached.

Thanks. This confirms my suspicion:

Oct 05 14:55:14 fedora gnome-shell[973]: Added device '/dev/dri/card0' (virtio_gpu) using atomic mode setting.

"virtio_gpu" isn't part of the deny list for atomic mode setting, which breaks the cursor hotspot.

Comment 19 Adam Williamson 2021-10-05 16:25:48 UTC
aha, and indeed, I'm using virtio in my affected VMs, and the time I started doing this probably does line up with when I started seeing the problem, now I think of it.

Comment 20 Adam Williamson 2021-10-05 16:26:38 UTC
It sounds like KDE would need to fix this separately, right?

Comment 21 Jonas Ådahl 2021-10-05 16:30:04 UTC
(In reply to Adam Williamson from comment #20)
> It sounds like KDE would need to fix this separately, right?

Yes, the fix here is in mutter.

Comment 22 Adam Williamson 2021-10-05 16:37:02 UTC
We could also fix it in F34, I guess. Wouldn't help the official lives, but would help installed VMs and the live respins (next time they're built).

Comment 23 Adam Williamson 2021-10-05 21:25:30 UTC
Filed https://bugzilla.redhat.com/show_bug.cgi?id=2011066 for the KDE/Plasma case.

Comment 24 Fedora Update System 2021-10-05 22:05:31 UTC
FEDORA-2021-4037e861a9 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4037e861a9

Comment 25 Fedora Update System 2021-10-05 22:05:51 UTC
FEDORA-2021-358f502f0e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-358f502f0e

Comment 26 Fedora Update System 2021-10-05 23:07:46 UTC
FEDORA-2021-358f502f0e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-358f502f0e

Comment 27 Geraldo Simião 2021-10-06 13:59:45 UTC
Created attachment 1829898 [details]
video of bug fixed with mutter-41.0-3

Upgraded to new mutter-41.0-3.fc35.x86_64 and now my VM running on virtio F35 workstation with wayland session works fine, no more cursor offset. Congrats :)

Comment 28 Kamil Páral 2021-10-06 14:07:12 UTC
Verified also by me.

Comment 29 Geraldo Simião 2021-10-06 15:25:42 UTC
(In reply to Fedora Update System from comment #26)
> FEDORA-2021-358f502f0e has been submitted as an update to Fedora 34.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-358f502f0e

update tested for F34 and bug fixed too, all is fine :)

Comment 30 Fedora Update System 2021-10-06 17:13:35 UTC
FEDORA-2021-358f502f0e has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-358f502f0e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-358f502f0e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 31 Fedora Update System 2021-10-07 15:53:26 UTC
FEDORA-2021-4037e861a9 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-4037e861a9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4037e861a9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 32 Fedora Update System 2021-10-07 17:18:35 UTC
FEDORA-2021-358f502f0e has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 33 Fedora Update System 2021-10-07 23:31:55 UTC
FEDORA-2021-4037e861a9 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.