> > > > > 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). > Honestly names are terrible, I would prefer SIDE_LEFT and SIDE_RIGHT. > I discovered using xinput that I have similar buttons on my mouse (never used). > > 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/ > > 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel