I’ve had to buy a new mouse, this time I got me a Logitech MX1000 (my first Logitech mouse ever). The Microsoft IntelliMouse Explorer I’ve used on my G5 got broken, it lost about two out of ten of clicks on the left button.
I’m not completely satisfied with the MX1000. It’s too heavy and a bit too small for my hands. The notable exception is the Forward button, it’s too far away from my thumb. I’ve had the last problem with the IntelliMouse Explorer too. I still have a few IntelliMouse Optical on other machines, I really like that mouse. Perfect Size, good wheel, easily reachable side buttons. The only drawback is the annoying big red light.
Anyhow, back to the MX1000. Only a few changes to my configuration for the IntelliMouse Explorer where needed to get it working. Here’s my new configuration:
Section "InputDevice" Identifier "MX1000" Driver "mouse" Option "CorePointer" Option "Protocol" "evdev" Option "Dev Name" "Logitech USB Receiver" Option "Buttons" "12" Option "ZAxisMapping" "11 12 10 9" Option "Resolution" "800" Option "Emulate3Buttons" "false" EndSection
! MX1000 pointer = 1 2 3 8 9 10 11 12 6 7 4 5
This gets the buttons in right order: Scrolling the wheel generates 4 and 5, tilting the wheel 6 and 7.
(You have to install
xvkbdfor this; I’m starting
# Backward and Forward buttons "xvkbd -text "\[Alt_L]\[Left]"" m:0x10 + b:8 "xvkbd -text "\[Alt_L]\[Right]"" m:0x10 + b:9 # "Cruise Control" disabled: #"xvkbd -text "\[Page_Up]"" # m:0x10 + b:11 #"xvkbd -text "\[Page_Down]"" # m:0x10 + b:12 # "Cruise Control" enabled: # Only use this if you have problems with Mozilla #"NoCommand" # m:0x10 + b:11 #"NoCommand" # m:0x10 + b:12 # Application-Switch button # A-Tab doesn't work # Use it as another Forward for now "xvkbd -text "\[Alt_L]\[Right]"" m:0x10 + b:10
Using the Application-Switch button for switching windows in GNOME doesn’t work because it would require holding down the Alt key while pressing Tab several times, xvkbd can’t do that. I’m using the button as another Forward now, it’s easier to reach than the real Forward button.
Defining actions for the Cruise Control buttons only makes sense when Cruise Control is disabled (you can disable it with the Logitech Mouse Applet). If it is disabled, the buttons generate 11 and 12. When it is enabled, they generate a single button 11 or 12 event and then a series of button 4 or 5 events just like scrolling the wheel does.
I have no idea why the mouse generates 11 or 12 before starting normal scrolling in Cruise Control mode. I’m mapping 11 and 12 to “NoCommand”, this eliminates the ButtonPress but not the ButtonRelease event. This seems to eliminate the negative effects of the extra button events in Mozilla. (Mozilla interprets the 11 and 12 events as normal left clicks, Firefox doesn’t have this issue. So if you’re using Firefox or if you don’t see the left-click problem with your Mozilla build, then don’t bind 11 and 12 to anything.)
- At this point the Backward and Forward buttons should work in GNOME, KDE, and Mozilla-based browsers. Horizontal scrolling should work in GNOME and KDE.
Mozilla-based browser like Firefox need two additional changes to get horizontal scrolling working with the tilt wheel: Open
mousewheel.horizscroll.withnokey.action = 0 mousewheel.horizscroll.withnokey.sysnumlines = true
April 5th, 2005: Update: Don’t bind 11/12 to anything in Cruise Control mode by default (only needed if there are problems with Mozilla). Fixed the "Cruise Control" comments in ~/.xbindkeysrc.
January 15th, 2006: Xorg 6.9 and later come with a different evdev driver. I’ve made an updated version of this guide now.