Red Hat Bugzilla – Bug 1285378
poor relative mouse behavior with spice on wayland host
Last modified: 2017-10-09 19:37:51 EDT
Description of problem:
I'm not able to move mouse across the whole remote screen when I connect to my Windows 7 virtual machine. The cursor stops before it reaches the position I want to point it to and the "boundary" changes all the time.
This worked in Fedora 22. I don't have this problem with virtual Fedoras or RHELs.
Version-Release number of selected component (if applicable):
I start the virtual machine this way:
qemu-kvm -smp 2 -vga qxl -soundhw ac97 -monitor stdio -spice port=5931,disable-ticketing -net nic,vlan=0,macaddr=... -net tap,vlan=0,ifname=tap2 -m 4096 -hda windows7.iso
This is actually related to Wayland. It works when I run on X.
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Sorry this didn't receive a response, but I haven't heard reports of this on F25 (which defaults to wayland), so I'm assuming it got fixed somewhere along the way. But if anyone can still reproduce, please reopen
I've just reproduced this on F25 on Wayland so I'm reopening this.
Thanks Marek. So this is F25 host with wayland, what's in the guest?
Was the VM created with virt-manager? If so, please provide sudo virsh dumpxml $vmname
Yes, the host is F25 and the guest is Windows 7 (it is also reproducible with Windows Server 2012).
I've created the VM with qemu-kvm, I just appended "-cdrom some-windows-install.iso" to the line from the description (the hda iso was created with qemu-img).
Btw, I have virt-viewer-5.0-1.fc25.x86_64 here.
I think if you add '-usbdevice tablet' to your command line it will give you better mouse performance, but the fact that the previous command changes behavior should be looked into.
It seems like spice relative mouse (non-tablet) has gotten worse on wayland, maybe it's fixable. Moving to spice-gtk. But in general using a tablet device is going to give better behavior anyways
*** Bug 1385211 has been marked as a duplicate of this bug. ***
*** Bug 1403755 has been marked as a duplicate of this bug. ***
It seems counter-intuitive to me that I'd need an emulated USB tablet device added to fix an emulated PS2 mouse. I tried it, and it doesn't really solve my problem. That is, it does solve the problem of there being two mouse pointers; now there's only one. However, with this new setup, left mouse clicks no longer register within the VM, which makes my whole Xorg session there unusable. So it's actually more broken for me this way than before.
Is spice agent installed in your guest ?
Is your guest configured to use the agent ?
I haven't installed the agent in the guest.
thanks - fedora and rhel have it installed by default - that would explain that they work
So the issue is Wayland client and SPICE mouse in the server mode.
spice-gtk uses some deprecated gdk function for mouse handling, it can be the cause of the issues
The root cause of this is that Wayland does not implement gdk_device_warp, which is required for server mode mouse
In server mode, we hide the client OS mouse cursor and we want to get relative mouse movement to send to the remote side. If we only rely on motion events, after some time we will stop being able to detect relative mouse movements as the mouse pointer will have reached the border of the screen and won't be able to move further. To avoid this, spice-gtk uses gdk_device_warp to keep the pointer in the middle of the screen(?) or spice-gtk window(?), this way we never hit the border of the screen, and can always infer relative mouse motion from it.
In wayland, gdk_device_warp is https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkdevice-wayland.c?h=gtk-3-22#n523
gdk_wayland_device_warp (GdkDevice *device,
so the mouse pointer does not stay fixed in the window, hits the border of the screen, and things end up not working as expected. You can set "SPICE_DEBUG_CURSOR" in your environment before running remote-viewer/spicy if you want to see the difference between wayland and X11.
Some discussion about this I had on #gtk+
14:59 < teuf> hey, gdk_device_warp() does not have an implementation on wayland, is that a waylandlimitation, or just some missing gtk+ code?
15:05 < mclasen> its not a good idea, even under X
15:07 < garnacho___> teuf: in theory could be implemented now with the pointer locking protocol, but it will only work if warping within a client surface
15:27 < teuf> hmm yeah "A relative pointer protocol (using wl_relative_pointer) has also been introduced that allows clients to continue receiving pointer movement deltas even when the pointer’s absolute position is clipped, such as on the edge of the monitor." really is what we would like to use (c&p'ing from https://blogs.s-osg.org/whats-new-wayland-weston-1-12/)
15:46 < garnacho___> teuf: it isn't handled in gtk+, but mutter does support it. Given spice-gtk is about the only legit user of this stuff from the gtk+ front, I wonder if it's an option to do this on the spice-gtk side, it certainly seems possible
15:49 < teuf> garnacho___: mozilla seems to be a second potential user ? https://bugzilla.gnome.org/show_bug.cgi?id=762662
15:49 < teuf> garnacho___: it might be an option, though I'd have absolutely no clue where to start doing that ;)
15:52 < mclasen> garnacho___: do we have a good answer for using custom protocols at the application level ?
15:52 < mclasen> would be nice to have that explained clearly
15:57 < garnacho___> mclasen: this indeed deserves a HowDoI, currently the best source of inspiration is https://git.gnome.org/browse/clutter-gtk/tree/clutter-gtk/gtk-clutter-embed.c
(In reply to Christophe Fergeau from comment #15)
> 15:46 < garnacho___> teuf: it isn't handled in gtk+, but mutter does support
> it. Given spice-gtk is about the only legit user of this stuff from the gtk+
> front, I wonder if it's an option to do this on the spice-gtk side, it
> certainly seems possible
> 15:49 < teuf> garnacho___: mozilla seems to be a second potential user ?
And gtk-vnc, and qemu ui/gtk.c
(In reply to Cole Robinson from comment #16)
> (In reply to Christophe Fergeau from comment #15)
> > 15:46 < garnacho___> teuf: it isn't handled in gtk+, but mutter does support
> > it. Given spice-gtk is about the only legit user of this stuff from the gtk+
> > front, I wonder if it's an option to do this on the spice-gtk side, it
> > certainly seems possible
> > 15:49 < teuf> garnacho___: mozilla seems to be a second potential user ?
> > https://bugzilla.gnome.org/show_bug.cgi?id=762662
> And gtk-vnc, and qemu ui/gtk.c
Indeed I am very much not in favour of the idea of all these apps having to re-implement the same code to talk to a custom wayland/mutter protocol instead of having gtk "just work" as before.
(In reply to Daniel Berrange from comment #17)
> Indeed I am very much not in favour of the idea of all these apps having to
> re-implement the same code to talk to a custom wayland/mutter protocol
> instead of having gtk "just work" as before.
Hi Daniel, I may agree those are not easy grounds for these apps, I however have some annotations over the "just works" remark.
- The low level "action, not mechanism" philosophy in X11 is very much leaked on the relevant Gdk API, you create a grab passing a confine_to window, and set the pointer position in global screen coordinates frequently. These semantics don't adapt really well to any other windowing system than X11, and trying to make each individual call and combination of arguments "just work" with the same semantics on any other windowing system is kind of a sham.
- More specifically to wayland, we must account that 1) a Gdk grab per-se has no signification beyond the client, it is always tied to one higher level operation, 2) "warp" and "confinement" happens on surface-local coordinates, and 3) there will be compositors that don't implement the necessary bits, thus the whole thing is failable in ways that it wasn't before.
So with the current API, gtk+ can just give a clunky appearance of "works" that might be enough for your usecases, provided that they run on the right compositor. Maybe it's worth to consider this for gtk+3 even if it involves touching deprecated calls, as wayland support there is a best effort. But I think this is better abstracted as a higher level mechanism. I personally wouldn't argue against having it in gtk+/gdk/, but still seems scarcely useful.
*** Bug 1415653 has been marked as a duplicate of this bug. ***
SDL implementation of this is https://hg.libsdl.org/SDL/rev/ee83e0b4a36f
Just to avoid duplicate work, some WIP code can be found at https://cgit.freedesktop.org/~teuf/spice-gtk/log/?h=wayland
For now, this only adds the glue to have SpiceWidget get notifications on relative mouse motions, and to confine the pointer to its window. Next will be to integrate that properly in the existing code base.
With the current state of packages in Fedora 26 and the same VM contents as before, I'm seeing definite improvements over Fedora 25. For me, there are still issues with the mouse pointer disappearing, and sometimes being confined to a portion of the screen, however, there's no doubled pointer issue, and it's generally more usable and less jumpy.
I have sent some proposed fix for this bug.