Red Hat Bugzilla – Bug 446660
evdev no longer recognizes mouse thumb button (mx revolution)
Last modified: 2018-04-11 09:08:58 EDT
In fedora 7 the evdev driver was able to see my mouses thumb button as button
17. In fedora 8 evdev did not work at all. Now in fedora 9, evdev is not
recognizing my mouses thumb button at all. In Fedora 9, if I run xev and press
the thumb button, nothing will print at all.
I have a Logitech MX Revolution mouse.
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 305810 [details]
My config file
Here is my xorg.conf file, not I cannot seem to get emulate3buttons to work
either, but that is another story.
Created attachment 305811 [details]
And here is my log file, (the word "not" should be "note" in the comment
Confirmed, the three thumb buttons activated by the thumb wheel don't work.
Okay, point of clarification. This mouse has *a lot* of buttons. If indeed the
thumb wheel has three buttons "wheel forward", "wheel backward", and "wheel
depress" (it feels like there may even be a fourth button, "wheel down"), then I
should add that the wheel forward and back buttons *never* worked in evdev. In
F7 only the thumb wheel depress what recognized.
Created attachment 309041 [details]
Honor button presses from mice with a lot of buttons
I too have this mouse. I tracked this problem down to the button codes for
manipulating the thumb dingus not being translated to X button events by evdev
because the button codes (0x118, 0x11A, and 0x11C) don't have symbolic constants
in linux/input.h. F8 evdev just used basic math to convert valid button ranges
back into X button events, so I modified it to go back to that behaviour.
This patch fixes it for me.
Fixed in evdev 2.0.2, available in F9 and rawhide.