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] log file And here is my log file, (the word "not" should be "note" in the comment above).
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.