New mice often have lots of buttons. Some buttons are used by X and some are used by Applications:
- 1,2,3: Left, middle and right mouse button
- 4,5: Y axis mouse wheel
- 6,7: X axis mouse wheel
- 8,9: Foward and backward in browsers usually
But other buttons are not mapped to any function mostly.
My Mad Catz R.A.T.5 mouse has an additional wheel which sends button event 10,11. I mapped this to volume up and down using xbindkeys.
If you like this functions add this to ~/.xbindkeysrc:
"aumix -v +1"
m:0x0 + b:10 (mouse)
"aumix -v -1"
m:0x0 + b:11 (mouse)
and start xbindkey on X11 session start. I use a line in ~/.xsession for this.
Problem: when you connect the Mad Catz R.A.T.5 mouse to a Linux box running openbox window manager, the window handling stops working. Sometimes mouse follow focus does not work, sometimes even clicking a window cannot activate it. Sometimes clicking window borders does not work, sometimes clicking into windows is ignored.
Solution: This mouse has a mode button, which is not sending a normal ButtonPress and ButtonRelease event, but it simulates a kind of holding shift function. e.g. pressing mode means holding Button13 and releasing Button14 and 15. Next time you press mode it’s holding Button14 and releasing Button13. There are several different modes. Openbox does weird things when these buttons are kept pressed. So I configured the xinput events to ignore buttons 13,14,15 by adding this line to my .xsession file:
xinput --set-button-map "Mad Catz Mad Catz R.A.T.5 Mouse" 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0
Version: tested with Debian 7.0