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'
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.

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

Hi,

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 ?
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

Hi,

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 

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

(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

(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. 
https://lists.freedesktop.org/archives/spice-devel/2017-October/040333.html

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 '28'.

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 28 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.

This bug appears to Fedora 30, and it should be reopen again.

I just hit this on Fedora 31 with qemu.

I'm having this problem on NixOS with sway.

here is a video of it: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-26c806e48db0

An upstream issue should be filed.

Opened issue upstream: https://bugs.launchpad.net/qemu/+bug/1859723

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
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 '30'.

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 30 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.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.