this device can be configured with the custom software (under windows), right? If so, did you change the wheel settings at all?

Unfortunately this isn't something we can work around in libinput because doing so would mean you lose the back/forward buttons. we can't tell the difference between a real button press and a mouse wheel, the look exactly the same.

So I recommend firing up the config software and changing how the wheel works.

> this device can be configured with the custom software (under windows), right?

Yes

> If so, did you change the wheel settings at all?

No, I never changed any settings. Are you saying that the software changes some settings inside the mouse itself, as opposed to OS/driver configuration?

> Unfortunately this isn't something we can work around in libinput because doing so would mean you lose the back/forward buttons. we can't tell the difference between a real button press and a mouse wheel, the look exactly the same.

You *can* tell the difference, at least for this very mouse model with its default configuration. As I've said, physical back and forward buttons map to BTN_SIDE and BTN_EXTRA, whereas the wheel maps to BTN_BACK/BTN_FORWARD.

If other mice map back/forward buttons to BTN_BACK/BTN_FORWARD, then this sounds to be a candidate for its own HWDB field. On the other hand, let me mention once again that back/forward buttons do work for me now, so maybe BTN_SIDE & BTN_EXTRA *is* what other mice emit for back/forward buttons.

Hope that this is not too confusing...

(In reply to Sergey Bugaev from comment #2)
> No, I never changed any settings. Are you saying that the software changes
> some settings inside the mouse itself, as opposed to OS/driver configuration?

yep, on many devices this is the case. google e.g. libratbag or solaar as projects to do exactly that.

> You *can* tell the difference, at least for this very mouse model with its
> default configuration. As I've said, physical back and forward buttons map
> to BTN_SIDE and BTN_EXTRA, whereas the wheel maps to BTN_BACK/BTN_FORWARD.

oh, right. I misread that while looking at the evemu outupt only

> If other mice map back/forward buttons to BTN_BACK/BTN_FORWARD, then this
> sounds to be a candidate for its own HWDB field. On the other hand, let me
> mention once again that back/forward buttons do work for me now, so maybe
> BTN_SIDE & BTN_EXTRA *is* what other mice emit for back/forward buttons.

yes, it's an unfortunate naming. the kernel has side/extra before back/forward, but most clients map buttons 4 and 5 (i.e. anything after LMR) to back/forward. I should probably document this in libinput too, just in case...

back to the RAT7: any configuration where back/forward would be mapped to other buttons? the thing with a hwdb is that it's not easily reversible, so by putting one in place we'd break it for anyone using the software to reconfigure the wheel. given these devices are gaming devices, that's assumed to be a large percentage.

I've done a brief research to confirm my assumption that this behavior is not unique to R.A.T. 7 (and so no hwdb entry is needed), and it seems to hold.

See,

* GNOME Files binds buttons 8/9 to back/forward: https://github.com/GNOME/nautilus/blob/master/src/nautilus-window.c#L74
* Firefox use[sd] 6/7 for horizontal scrolling (no longer supported; deprecated in favor of native wheel events) and 8/9 for back/forward: https://github.com/mozilla/gecko-dev/commit/8c7fedbebdf7a8d10085ae7284dce334f1d019a8
* Here, Olivier Crête states: "I'm attaching a simple patch that maps X mouse buttons 8-9 to the back/forward commands. The consensus amongst GTK+ and Qt seems to be that buttons 6-7 are for horizontal scrolling." https://bugzilla.mozilla.org/show_bug.cgi?id=355477

These all are seemingly codes from linux/input-event-codes.h taken relative to BUTTON_BASE, which is BTN_LEFT - 1 (https://github.com/GNOME/gtk/blob/master/gdk/wayland/gdkdevice-wayland.c#L47) and plus 4 (https://github.com/GNOME/gtk/blob/master/gdk/wayland/gdkdevice-wayland.c#L1618, mentioning "old 4-7 scroll ones").

This leaves us with the following:
* BTN_SIDE is button 8, used for the "back" command
* BTN_EXTRA is button 9, used for the "forward" command
* BTN_FORWARD is button 10 (or 6 without +4), should mean scrolling left
* BTN_BACK is button 11 (or 7 without +4), should mean scrolling right

Have you actually tested other mice with extra buttons & wheels? How do they behave?

for an overview on button mapping in X see: https://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html, but the basic summary is: physical buttons 1, 2, 3, 4, 5 are mapped into logical buttons 1, 2, 3, 8, 9 because logical buttons 4-7 are reserved for vertical and horizontal scroll wheel clicks. That is done because when scroll wheels showed up the X protocol didn't have any ability to send separate axis events, so they were sent as clicks. That is a *convention* only though, i.e. a client could in theory use button 4 as a normal button click. No sensible client does so, of course :)

With the evdev driver and libinput as well, the mapping is not static between kernel event codes and logical codes. We merely run up the event codes and fill in the mapping as codes exist, so if you have BTN_SIDE and BTN_FORWARD but not the others, those will be assigned mappings 8 and 9 (back and forward). That's done because the hid mappings of the buttons aren't always consistent on mice and some devices merely fill in the buttons numerically (leading to the BTN_SIDE mapping for what should be BTN_BACK).

For this specific device, the problem is that the scroll wheel sends button events. libinput has a couple of promises regarding wheel events, so what we would have to do is convert these button presses into wheel clicks or tilts inside libinput so it is never passed on as button press. But as I said above, I'm hesitant to do this because this device is configurable, so shipping a quirk like this would break any custom configuration on this device with little options to work around it.

Thanks for the explanation! Still, you haven't replied about what other mice emit for scroll events.

>> No, I never changed any settings. Are you saying that the software changes
>> some settings inside the mouse itself, as opposed to OS/driver configuration?

> yep, on many devices this is the case. google e.g. libratbag or solaar as projects to do exactly that.

For R.A.T., I found ratctl (https://github.com/MayeulC/Saitek), which claims to have completely reverse-engineered the USB protocol. Here's what the author says about it (https://github.com/MayeulC/Saitek/issues/4#issuecomment-283506849):

>> I'm not talking about tweaking the computer settings... is there a way to re-program the mouse itself, or what does the Windows/macOS configuration software that ships with the mouse do?

> Not as far as I know. I am reasonably certain that these utilities either change the driver behavior, or generate virtual events that are directly interpreted by the windowing system.

So it should be safe to either add hwdb entry (if this mouse is rather unique) or change it for all mice, if they all emit events this way.

By the way, if this button-mapping configuration is a client-side thing, it would be cool if GNOME offered a settings panel for it, like it does for Wacom tablet/styluses. I realize that this is a wrong place to ask for that -- but what changes to libinput would it take to make that possible?

(In reply to Sergey Bugaev from comment #6)
> Thanks for the explanation! Still, you haven't replied about what other mice
> emit for scroll events.

REL_WHEEL and REL_HWHEEL, respectively. I think I have a mouse that sends REL_DIAL but that's something that needs to be fixed.

> >> No, I never changed any settings. Are you saying that the software changes
> >> some settings inside the mouse itself, as opposed to OS/driver configuration?
> 
> > yep, on many devices this is the case. google e.g. libratbag or solaar as projects to do exactly that.
> 
> For R.A.T., I found ratctl (https://github.com/MayeulC/Saitek), which claims
> to have completely reverse-engineered the USB protocol. Here's what the
> author says about it
> (https://github.com/MayeulC/Saitek/issues/4#issuecomment-283506849):
> 
> >> I'm not talking about tweaking the computer settings... is there a way to re-program the mouse itself, or what does the Windows/macOS configuration software that ships with the mouse do?
> 
> > Not as far as I know. I am reasonably certain that these utilities either change the driver behavior, or generate virtual events that are directly interpreted by the windowing system.

I can't speak for the RAT devices but Logitech devices and a bunch of others
definitely store this stuff in the device itself. In fact, libratbag *only*
supports devices that use hardware storage. The best way to find out is to
find a windows install and check.

> So it should be safe to either add hwdb entry (if this mouse is rather
> unique) or change it for all mice, if they all emit events this way.

no other mouse does this, to my knowledge, and before we can add a hwdb
entry I'd need confirmation that it is impossible to remap the wheel in the
windows software. And in that case, it's likely worth doing this in the
kernel anyway, remapping in libinput is a lot more complicated.

> By the way, if this button-mapping configuration is a client-side thing, it
> would be cool if GNOME offered a settings panel for it, like it does for
> Wacom tablet/styluses. I realize that this is a wrong place to ask for that
> -- but what changes to libinput would it take to make that possible?

out of scope for libinput because it modifies the device directly. libratbag
is a project we started to do this and it has piper as a (temporary)
interface. I talked to the gnome guys and it's basically down to: this is a
rarely used thing, highly device-specific, relatively rare compared to the
general user base and it's all stored on the device itself, so it's not
suitable as control panel applet but better as standalone application.