I am writing a spice client from scratch that only connects to the main and input channels for sending mouse and keyboard events. I have discovered two issues with spice/qemu and a Windows 10 guest. 1) If the tablet and mouse are attached and SPICE_MOUSE_MODE_SERVER is in use, sending SPICE_MSGC_INPUTS_MOUSE_PRESS performs it at the location of the tablet rather then the location of the cursor, causing the cursor to jump back to it's original location. 2) If SPICE_MOUSE_MODE_CLIENT is in use, applications that need relative input event's do not work properly, first person games for example only allow a 180 degree turn due to the cursor hitting the x/y bounds. After removing the tablet and setting to SPICE_MOUSE_MODE_SERVER both 1 & 2 are worked around, but this exposes what looks like a more major bug in Spice or qemu, I am not sure where the fault lies. 3) With SPICE_MOUSE_MODE_SERVER, only a generic mouse attached, if the mouse is moved around and SPICE_MSGC_INPUTS_KEY_DOWN/UP messages are sent, the guest cursor quickly stops responding and never recovers. It seems spice-server continues to perform properly as it continues to send SPICE_MSG_INPUTS_MOUSE_MOTION_ACK every 4 mouse messages, and keyboard events continue to function properly. This indicates it is not a problem with my client, but a failure between spice-server and qemu. I will continue to dig into qemu/spice to try to discover what is broken here, but it would be great if someone with more experience with spice could have a look too.
Further investigation shows very odd behavior where the mouse seems to interact with the keyboard scan code. Tracing qemu a AUX_RESET is written to the mouse just after this. I found the following bug report that is exhibiting the exact same behavior I am seeing here. It looks like this is a qemu bug, not spice. https://openxt.atlassian.net/browse/OXT-562
I have opened the following bug for qemu where I will continue this. https://bugs.launchpad.net/qemu/+bug/1722884
Regarding 1), this could just be a corner case which was never noticed when using spice-gtk. For 2), I would say this depends on how the application implements the relative motion. client mouse position reporting will indeed be clamped to the screen.
> Regarding 1), this could just be a corner case which was never noticed when using spice-gtk. I would certainly say so, but it isn't a spice bug, it's a qemu bug with the i8042 controller, windows 10 shows in the event log that the device stops working, and verbose debugging shows that windows gets sent PS2 data as keyboard data, and keyboard data as ps2 data when both are active at the same time.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.