

Then the game table scrolls left to right, but I have to have the mouse over the bottom scroll bar in the browser at all times to do this. I can Horizontal Scroll (Left & Right) the Page Toolbar with all the game table maps by holding Shift + Mouse Wheel and I can also Horizontal Scroll (Left & Right) the Game Map, if I mouse over the scroll bar at the bottom of the browser window and hold Shift + Mouse Wheel. I am using a PC with Windows 8 and running Roll20 in Chrome. My guess is that it's probably not fixed, yet.Īlso note that, on Windows, pushing the scroll wheel sideways first results in forward/backward, too, but after installing the Lenovo driver, it seems to be mapped in software to do horizontal scrolling by default (but can also be programmed in many other ways).I am experiencing the same problem. Please note that I'm using Debian 9 with "ancient" libinput 1.6.3, but I couldn't find an according quirk entry in libinput 1.12.6 (from Debian testing), either. As I couldn't find an existing bug report, I'm now reporting this myself. The issue was previously reported here, where Peter Hutterer suggested to file a bug on libinput to have a hwdb quirk in libinput for this mouse.


In evemu-record-20190629-3.log, I hold it down longer to show there is no repeat kicking in. In evemu-record-20190629-1.log, I first press the mouse wheel left, release, then right, release. (Expected behaviour, like seen on another mouse: Keep scrolling.) Also, there does not seem to be axis changes reported when doing so, but I don't know whether they should be reported by the hardware, the kernel, libinput or where else. When remapping via xinput -set-button-map 18 1 2 3 4 5 0 0 6 7, pressing the mouse wheel sideways produces exactly one horizontal scroll step. Hi, in xorg this mouse does not seem to send buttons 6/7 for pressing the mouse wheel sideways, but 8/9, so acts as forward/backward by default.
