Created attachment 20522 [details] [review] Adds scroll wheel support for keyboards I have an A4Tech KBS26 multimedia keyboard with a scroll wheel on it. It uses special scan codes for the wheel movement, encoding the scrolled distance into the scancode itself, and uses the key up / down bits to indicate scroll direction(so scrolling down always results in key release events). Wit the "scroll=1" option given to the atkb module, the kernel is able to recognize these scancodes and exports them as relative motion events: $ input-events 3 /dev/input/event3 bustype : BUS_I8042 vendor : 0x1 product : 0x1 version : 43841 name : "AT Translated Set 2 keyboard" phys : "isa0060/serio0/input0" bits ev : EV_SYN EV_KEY EV_REL EV_MSC EV_LED EV_REP waiting for events 16:28:12.927179: EV_SYN code=0 value=0 16:28:21.150517: EV_MSC code=4 value=139 16:28:21.150531: EV_REL REL_WHEEL -1 16:28:21.150536: EV_SYN code=0 value=0 16:28:21.194458: EV_MSC code=4 value=145 16:28:21.194478: EV_REL REL_WHEEL -2 16:28:21.194482: EV_SYN code=0 value=0 16:28:21.224686: EV_MSC code=4 value=146 16:28:21.224705: EV_REL REL_WHEEL -4 16:28:21.224709: EV_SYN code=0 value=0 16:28:22.419020: EV_MSC code=4 value=159 16:28:22.419039: EV_REL REL_WHEEL 8 16:28:22.419044: EV_SYN code=0 value=0 16:28:22.432139: EV_MSC code=4 value=159 16:28:22.432152: EV_REL REL_WHEEL 8 16:28:22.432156: EV_SYN code=0 value=0 The xorg evdev driver recognizes these EV_REL events and sends them to the sever as mouse button 4 and 5 presses. However, because the device is configured as keyboard, these events seem to be ignored by the server. Bellow is a patch against the latest master branch that works around this limitation by initializing the keyboard as pointing device in case it supports wheel events. The solution is a bit hackish, but should work for other keyboards that expose scrollwheel events.
On Sun, Nov 23, 2008 at 07:26:01AM -0800, bugzilla-daemon@freedesktop.org wrote: > The xorg evdev driver recognizes these EV_REL events and sends them to the > sever as mouse button 4 and 5 presses. However, because the device is > configured as keyboard, these events seem to be ignored by the server. Bellow > is a patch against the latest master branch that works around this limitation > by initializing the keyboard as pointing device in case it supports wheel > events. The solution is a bit hackish, but should work for other keyboards that > expose scrollwheel events. Why do you only enable the code if it's a keyboard? (Hunk 5) Shouldn't this check be outside of the keyboard description? Please fix up the indentation, looks like two hunks use different indentation than the surrounding code. Other than that - if it works for you, then ACK. Please attach the amended patch as a git commit (git-format-patch).
Created attachment 20562 [details] [review] [PATCH] Support keyboards with scroll wheels. Here is a new version with some cleanups. I tried to correct the indentation, I hope to have gotten it right this time. Regarding the keyboard-specific setup: initially I intended to minimize the impact on the code, because I couldn't make sure that by setting those extra flags I didn't accidentally break something. But you are right: there might be exotic input devices out there that support wheel events, but are not mice or touchpads, so it might be beneficial to have the scrolling support enabled for those, too. I changed the code accordingly: it now sets those flags for every device that support scroll events but is not configured as a pointing device. Note: I tested tested against xorg-server 1.5.2.
Thanks, I got it in my tree now and it will find its way upstream within a few days. Please close this bug as FIXED once you find the patch upstream (in case I forget to do so).
Pushed as 2bd24649ecbae08b7bd4dacd67d141ae665f8db7. Thanks for the patch.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.