On 02/11/2017 12:53, Matthew J. Francis wrote:
Based on some research into what would be required to support this through the SPICE stack, the implications for the protocol (an extra message), server (extra methods in the mouse and tablet interfaces) and spice-gtk (fairly easy plumbing) seem mostly obvious. For xf86-video-qxl, XInput >= 2.1 supports smooth scrolling events, which GDK then consumes to provide the necessary support to Gtk+ on X11. With some not-quite-trivial changes, this should therefore be able to be supported under the direct tablet input mode, as both the information on the type of scroll event and the ability to inject smooth scrolling events (or not) exist in the same place. For agent mouse mode, things are more complicated. After the round trip through vdagent, events come back into xorg in uinput format. To implement smooth scrolling for a real tablet device, I believe that the X input device has to process multi-touch uinput events - i.e. to support this using uinput semantics, I think we would have to pretend to be two fingers moving from the last known cursor position. The same basic principle would seem to apply to implementing this in qemu. Supporting smooth scrolling through a hardware tablet interface (whether usb, virtio, ...) would mean emulating moving fingers, which sounds like a recipe for trouble - if that were to be consumed in a non-multitouch-aware context, scrolling would translate to unwanted mouse movement. Given also the potential difficulty of getting qemu to accept such a nasty hack at that level, it seems to me that an optional vdagent (agent mouse) feature is probably the best way to go. Windows is again not my area of speciality, but a brief search suggests vdagent should be able to inject the correct events there.
Following up to myself: I got at least two things wrong in the above analysis. Firstly, in the Xspice case, we control both ends of the fake uinput connection (written to by vdagentd, read from by the "xspice pointer" driver in spiceqxl_inputs.c). However, I hadn't considered that when running X under qemu, we only control the vdagentd end, and input is handled by xorg's generic libinput driver - or indeed wayland, or whatever else uses the mouse. Secondly, I managed to conflate trackpads and tablets in my mind when thinking about how to stuff the required information through uinput. This wouldn't matter much in the Xspice case, where we should be more or less able to stuff what we like over "uinput" provided that the "xspice pointer" driver is prepared to deal with it, but in the X-under-qemu case the capabilities of the pointer device have to be consistent - and trying for instance to simulate trackpad gestures on a tablet isn't likely to get far. So, back to being not sure what a reasonable solution looks like for that combination, with the basic constraint that there doesn't seem to be a general way to pass wheel events over uinput in a manner such that generic drivers reading the information will understand that the wheels are high resolution. I do see one patch[1] that relates to an attempt to solve the issue for one particular sort of mouse - but only for vertical wheel (argh), and I can't find any associated discussion to suggest if the patch has actually gone anywhere. Regards Matthew Francis [1] https://patchwork.kernel.org/patch/9675301/ _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel