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

[Frediano Ziglio]

> 
> 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.

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

> 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 

> 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.

> * 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