<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - No horizontal scrolling with mouse" href="https://bugs.freedesktop.org/show_bug.cgi?id=99554#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - No horizontal scrolling with mouse" href="https://bugs.freedesktop.org/show_bug.cgi?id=99554">bug 99554</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>for an overview on button mapping in X see: <a href="https://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html">https://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html</a>, 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>