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:
-
/etc/X11/XF86Config-4
or/etc/X11/xorg.conf
: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
-
/etc/X11/Xmodmap
:! 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.
-
~/.xbindkeysrc
:
(You have to installxbindkeys
andxvkbd
for this; I’m startingxbindkeys
in~/.gnomerc
)# 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: Openabout:config
and setmousewheel.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.
Jouko Pynnönen has discovered an argument injection vulnerability in Java Web Start. I’ve just created a new Blackdown security advisory about this problem. Note that our current releases are not affected.
The Exim 4 source code supports authentication with SASL since version 4.43. Debian started enabling this feature in exim4_4.50-2. After I’ve had upgraded to that version and replaced my saslauthd authenticators with brand-new cyrus_sasl authenticators, I’ve noticed that auth.log
got flooded with entries like ‘exim4: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory
.’
My exim configuration uses three different cyrus_sasl authenticators and each exim invocation resulted in three of these OTP warnings because exim calls sasl_listmech()
for each configured authenticator. It doesn’t specify a limiting mech_list
, that means SASL will test which of all installed mechs actually can be used for authentication. Debian’s SASL package includes libotp.so
, so it also tries to use OTP which is not configured on my system.
There are two ways to get rid off the warnings:
- Remove
/usr/lib/sasl2/libotp.*
. You’ll have to do this after each upgrade of the libsasl2-modules package. - Rebuild exim with this patch. The patch specifies a limiting
mech_list
option for SASL. This limitssasl_listmech()
to the mechs used in the exim configuration. Other mechs won’t be tried anymore.
May 3rd, 2005: A slightly modified version of the patch has been integrated into Exim CVS and will be included in the next Debian release of exim4 (see Debian bug #299743)
The inotify API has been changed, watches are now added via the file’s fd. That makes the 32-bit compat patch pretty trivial:
inotify-0.21-compat.patch
March 18th, 2005: The patch has been integrated into inotify 0.21-2
My 32-bit compat patch for evdev has been integrated into Linux 2.6.11-mm3.