[Spice-devel] [3/6] [PATCH spice] Add horizontal mouse wheel support

[Matthew J. Francis]

On 07/11/2017 01:49, Christophe Fergeau wrote:

> One note here, when running a wayland spice-gtk/remote-viewer, the only
> scroll events I'm getting are GDK_SCROLL_SMOOTH events, I'm not getting
> any scroll event until I add GDK_SMOOTH_SCROLL_MASK to the events
> spice-gtk listens to (which results in the mouse wheel not being
> functional with a wayland client).

With both GDK_SCROLL_MASK and GDK_SMOOTH_SCROLL_MASK set, it seems that
GDK filters to make sure that only one event is delivered *if* a backend
generates both sorts, but it does not simulate non-smooth scrolls in its
common code.
In the case of X, XInput appears to issue both a smooth event and an
emulated non-smooth event beneath the level of GDK.
In the case of macOS, gdkevents-quartz.c generates an equivalent
emulated event at the GDK backend level.
However, nothing appears to do so in the Wayland backend, leading to the
behaviour you note.

Another requirement then, if that is the case - we need to be able to
synthesise old-style events if all we have is smooth input.

Given the possibility of talking to a server that doesn't know anything
about smooth scrolling, this will have to be a spice-gtk feature in the
first instance for scrolling to work in all cases with a Wayland client.

To tell the client when it should send smooth scroll events unconverted
to the server, the inputs channel should have a capability. In theory we
could set this capability or not depending on whether a suitable input
interface is connected and/or agent mouse mode is set. However, as agent
mouse mode is the default and will virtually always be set, it may make
sense just to unconditionally advertise this capability in order to
reduce the space of possible configurations (eliminating a combination
that will be rarely used and thus poorly tested in practice).

In either case, when using agent mouse mode, the capability must always
be offered, and the server will also have to be able to perform its own
conversion of scroll events while a vdagent with the relevant support is
not connected (one may not actually be connected initially, or at all).


I'm still looking for a good solution for the qemu + X/Wayland case.
It's possible the answer may be a patch to libinput - I will experiment
to see if it can work at that level, and propose a patch if so.

Regards
Matthew Francis