[Spice-devel] Adding support for mouse buttons SIDE and EXTRA (often scroll wheel push left or right)

[james harvey]

I added in those involved in Oct 25, 2017'ish discussion regarding
horizontal mouse wheel support, from here:
https://patchwork.freedesktop.org/series/32626/

I'm not sure if that patchset was officially rejected.

Regarding comments in that patcheset, because a native qemu (no spice
involved) window can handle these buttons, I don't know if anything
(or much) would need to be changed in qemu.

On Mon, Dec 17, 2018 at 2:42 PM Frediano Ziglio <fziglio at redhat.com> wrote:
> > > I have a Logitech G600 mouse.  The scroll wheel can be pushed left or
> > > right.
> > >
> > > On Arch Linux host, evtest shows these as event codes 275 (BTN_SIDE)
> > > and 276 (BTN_EXTRA.)  On host, they work as expected, by default as
> > > back and forward in supported programs such as web browsers.
> > >
> > > There are so many mice which generate these events, going all the way
> > > back to the IntelliMouse Explorer in 1999.
> > >
> > > QEMU supports these buttons.  For default PS/2 mouse emulation
> > > support, see https://github.com/qemu/qemu/blob/master/hw/input/ps2.c
> > > :700-701.  For "-device virtio-mouse-pci" support, see
> > > https://github.com/qemu/qemu/blob/master/hw/input/virtio-input-hid.c :
> > > 31-32.  On an Arch guest, evtest shows an "ImExPS/2 Generic Explorer
> > > Mouse" or a "QEMU Virtio Mouse", both of which list the event codes as
> > > supported.  On Windows 7 guest, Device Manager can be manually set to
> > > a "Microsoft - Microsoft PS/2 Mouse" instead of the default "Microsoft
> > > - PS/2 Compatible Mouse" driver, which forces IntelliMouse Explorer
> > > mode to allow usage of the extra buttons.
> > >
> > > "remote-viewer --spice-debug" shows the events:
> > >
> > > (remote-viewer:14226): GSpice-DEBUG: 17:09:00.043: spice-widget.c:2007
> > > 0:0 button_event press: button 8, state 0x10
> > > (remote-viewer:14226): GSpice-DEBUG: 17:09:00.414: spice-widget.c:2007
> > > 0:0 button_event release: button 8, state 0x10
> > > (remote-viewer:14226): GSpice-DEBUG: 17:09:01.045: spice-widget.c:2007
> > > 0:0 button_event press: button 9, state 0x10
> > > (remote-viewer:14226): GSpice-DEBUG: 17:09:01.473: spice-widget.c:2007
> > > 0:0 button_event release: button 9, state 0x10
> > >
> >
> > From
> > https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkEventButton
> > these buttons should not even exist. Wondering what are button 6 and 7.
> >
>
> I dig a bit in the Gdk code and unfortunately these numbers came directly
> from X11 so they are subject to change with the system you are using
> (won't work on Windows for instance).

By "the system", do you mean the one the client is running on, or the
guest you're connecting to?  That's too bad.  Does that effectively
block Matthew Francis' patchset from this being accepted into spice?
Is this something users would have to patch in and compile if they
wanted it?  Would spice need for GTK to make these documented events
before implementing it?  Perhaps a configuration could be added to map
the buttons per what the system gives, but I realize that greatly
enlarges the scope of the changes.

> > Honestly names are terrible, I would prefer SIDE_LEFT and SIDE_RIGHT.

No argument there.  I was confused by the names being given.

> > > But, the guest never receives them, because spice doesn't appear to handle
> > > them.
> > >
> > > It doesn't look like adding support for these should be many lines.  I
> > > was trying to write a patch, but got a bit lost.
> > >
> > >
> > > spice-protocol::spice/enums.h only gives SpiceMouseButton types of
> > > LEFT, MIDDLE, RIGHT, UP, and DOWN.  _SIDE and _EXTRA need to be added
> > > here.  If they're merely added, in c, they'd be represented by ints 6
> > > and 7.  I'm not sure if (2) _INVALID types would need to be left in
> > > the middle to make their internal representation match the button
> > > numbers that "remote-viewer --spice-debug" is showing.  (That's mainly
> > > because I'm not sure where these values are ultimately "decoded" into
> > > causing QEMU mouse events.)
> > >
> >
> > Don't confuse SPICE constant with Gdk ones, you/we need to change
> > spice.proto (see mouse_button) in spice-common and generate enums.h
> >
>
> There's a similar (not integrated) series at https://patchwork.freedesktop.org/series/32626/

That's a great find.

> > > spice-gtk::src/spice-widget.c::button_event() calls:
> > >
> > > * button_gdk_to_spice() which also only gives the same 5 button types
> > > and returns 0 for button 8 or 9, so the event winds up never getting
> > > passing along.  _SIDE and _EXTRA need to be added here.  I'm not sure
> > > if they should be sequentially added as ints 6 and 7, or if (2)
> > > _INVALID types need to be added here for padding as well.
> > >
> >
> > No problem, compiler with sort the holes for you.
> >
>
> with -> will
>
> > > * button_mask_gdk_to_spice() which might also need something added.
> > > I'm not sure why a mask is being used regarding the button state, let
> > > alone how to convert it.
> > >
> >
> > Depends if these button finish in the state, from your previous messages
> > seems not. The idea is that for instance the system can do a different action
> > if some modifier is enabled, for instance CTRL-Right_click or just
> > Right_click.
> > Not all buttons end up in the state.
> >
> > > * spice_inputs_channel_button_{press,release}() which might also need
> > > state mask handling in its switch().
> > >
> >
> > Not necessarily, as stated above.
> >
> > > From there, msg->marshallers->msgc_inputs_mouse_{press,release}() are
> > > called.  Those threw me, and during the build process are generated as
> > > src/spice-gtk/subprojects/spice-common/common/generated_client_marshellers.c.
> > > They don't look like they need to be modified.
> > >
> >
> > Right
> >
> > > I'm not sure where that message is received, or where it generates (I
> > > presume) a mouse event through QEMU.
> >
> > They will be handled in inputs_channel_handle_message in
> > server/inputs-channel.c
> > (spice-server). On the server additional code is required to communicate the
> > new buttons to Qemu.
> >
>
> Frediano