Bug 1285378 - poor relative mouse behavior with spice on wayland host
poor relative mouse behavior with spice on wayland host
Status: NEW
Product: Fedora
Classification: Fedora
Component: spice-gtk (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Marc-Andre Lureau
Fedora Extras Quality Assurance
: Reopened
: 1385211 1403755 1415653 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-25 08:53 EST by Marek Kašík
Modified: 2017-10-09 19:37 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-12 16:20:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marek Kašík 2015-11-25 08:53:29 EST
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):
virt-viewer-2.0-2.fc23.x86_64

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
Comment 1 Marek Kašík 2015-11-26 10:30:13 EST
This is actually related to Wayland. It works when I run on X.
Comment 2 Fedora End Of Life 2016-11-24 08:44:03 EST
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'
of '23'.

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.
Comment 3 Cole Robinson 2016-12-12 16:20:18 EST
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
Comment 4 Marek Kašík 2016-12-13 08:22:36 EST
Hi,

I've just reproduced this on F25 on Wayland so I'm reopening this.
Comment 5 Cole Robinson 2016-12-13 13:10:59 EST
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
Comment 6 Marek Kašík 2016-12-14 05:17:15 EST
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.
Comment 7 Cole Robinson 2016-12-14 10:26:50 EST
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.
Comment 8 Cole Robinson 2016-12-14 10:29:08 EST
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
Comment 9 Cole Robinson 2016-12-14 10:32:13 EST
*** Bug 1385211 has been marked as a duplicate of this bug. ***
Comment 10 Cole Robinson 2016-12-14 10:32:48 EST
*** Bug 1403755 has been marked as a duplicate of this bug. ***
Comment 11 David H. Gutteridge 2016-12-15 16:10:49 EST
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.
Comment 12 Pavel Grunt 2016-12-21 05:36:07 EST
Is spice agent installed in your guest ?
https://www.spice-space.org/download.html

Is your guest configured to use the agent ?
https://www.spice-space.org/spice-user-manual.html#agent
Comment 13 Marek Kašík 2016-12-21 05:45:28 EST
Hi,

I haven't installed the agent in the guest.
Comment 14 Pavel Grunt 2016-12-21 06:55:24 EST
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
Comment 15 Christophe Fergeau 2016-12-22 04:33:50 EST
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 

static void
gdk_wayland_device_warp (GdkDevice *device,
                         GdkScreen *screen,
                         gdouble    x,
                         gdouble    y)
{
}

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
Comment 16 Cole Robinson 2016-12-22 05:28:06 EST
(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
Comment 17 Daniel Berrange 2016-12-22 05:44:45 EST
(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.
Comment 18 Carlos Garnacho 2016-12-22 07:51:35 EST
(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.
Comment 19 Pavel Grunt 2017-01-23 11:25:24 EST
*** Bug 1415653 has been marked as a duplicate of this bug. ***
Comment 20 Christophe Fergeau 2017-03-24 13:28:50 EDT
SDL implementation of this is https://hg.libsdl.org/SDL/rev/ee83e0b4a36f
Comment 21 Christophe Fergeau 2017-04-04 05:50:31 EDT
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.
Comment 22 David H. Gutteridge 2017-09-02 14:13:00 EDT
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.
Comment 23 Marie Stephanie Alesna 2017-10-09 19:37:51 EDT
I have sent some proposed fix for this bug. 
https://lists.freedesktop.org/archives/spice-devel/2017-October/040333.html

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