On 01/11/2017 01:20, Christophe de Dinechin wrote:
Matthew J. Francis writes:
What requirements might there be in terms of touch pads?
I would expect touch pads (and some mice) to send events that have
delta_x and delta_y in the same GdkEventScroll message. Some testing on
macOS with a MacBook trackpad gives me something like:
spice-widget.c:2035: [103 28.932795] scroll_event: going down: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=0.900009
spice-widget.c:2035: [104 28.973638] scroll_event: going down: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=1.000000
spice-widget.c:2035: [105 28.983640] scroll_event: going left: x=327.000000 y=332.000000 delta_x=0.800003 delta_y=0.000000
spice-widget.c:2035: [107 29.015997] scroll_event: going left: x=327.000000 y=332.000000 delta_x=1.000000 delta_y=0.000000
spice-widget.c:2035: [109 29.056910] scroll_event: going left: x=327.000000 y=332.000000 delta_x=1.200012 delta_y=0.000000
spice-widget.c:2035: [111 29.091373] scroll_event: going up: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=1.000000
spice-widget.c:2035: [112 29.123201] scroll_event: going up: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=1.300003
spice-widget.c:2035: [113 29.155868] scroll_event: going up: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=1.300003
spice-widget.c:2035: [114 29.180780] scroll_event: going right: x=327.000000 y=332.000000 delta_x=0.800003 delta_y=0.000000
spice-widget.c:2035: [116 29.214177] scroll_event: going right: x=327.000000 y=332.000000 delta_x=0.900009 delta_y=0.000000
spice-widget.c:2035: [118 29.256171] scroll_event: going right: x=327.000000 y=332.000000 delta_x=0.900009 delta_y=0.000000
spice-widget.c:2035: [120 29.338235] scroll_event: going down: x=327.000000 y=332.000000 delta_x=0.000000 delta_y=0.600006
So it looks like I never get the GDK_SCROLL_SMOOTH event, and that
otherwise the delta_x and delta_y values are garbage (I was hoping for
+/-1 there for up/down events).
But if you feel like bumping the protocol, maybe you could also add
support for GDK_SCROLL_SMOOTH, and convert everything to delta_x /
delta_y messages.
The above looks like you have maybe not set SMOOTH_SCROLL_MASK in the
gdk event mask? If I set it, I get GDK_SCROLL_SMOOTH events from my
Magic Mouse 2 with both delta_x and delta_y in the same event.
As to the content of delta_x and delta_y in the non-smooth case, it
looks like the handling of this is not particularly uniform between
the different gdk backends in terms of what is left in the event - but -
if you use gdk_event_get_scroll_deltas() to get them, it correctly
zeroes out the values if the event is not GDK_SCROLL_SMOOTH.
(zero is the correct value for non-smooth, rather than +/-1, as the two
concepts are not comparable - the old way conceptually counts "lines of
text" moved, a step of some arbitrary size, while smooth scrolling
counts "pixels")
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.
To sum up, the following seems possible.
- Xspice, no vdagent: YES
- Xspice, with vdagent: YES
- Qemu, Linux/X, no vdagent: NO
- Qemu, Linux/X, with vdagent: YES
- Qemu, Windows, no vdagent: NO
- Qemu, Windows, with vdagent: YES
Regards
Matthew Francis
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel