Archive for 2006-04-18

When Logitech MX1000 mice was just out, its Linux support is mediocre at best, I’d say. During early days (when there is no good evdev support both on kernel side and on Xorg/XFree86), the best reference on how to make it work was in linux-gamers.net (the old page documenting Gentoo hack was gone; and don’t be disappointed, it gets a face lift. This new shiny page details the most recent situation).

Kernel: The necessary evdev support is only getting its shape in recent 2.6.x versions. 1-2 years ago it was still in embryo form, and not very usable. Right now it’s much better; but still, I got strange result from evdev. More on that later.

Xorg: During 6.8.x days, the Gentoo hack was the best attempt to make it work; right now the generic evdev input driver works better in Xorg 6.9/7.0. But getting the correct xorg.conf setting isn’t easy. So far all of the xorg.conf snipplets suggest using a hard-coded device, but I liked the old Gentoo hack that supports using device name instead, like:

Section "InputDevice"
  ......
  Option "Dev Name" "Logitech USB Receiver"
  ......
EndSection

In that way there is no need to attempt finding the correct device name, which may change from time to time (this is especially the case for me, since I’m only using MX1000 at home as CorePointer). Hope the XInput hotplug support, after implemented, makes mice really “plug and play”, without restarting and restarting and restarting X…

Besides, there is apparently no evdev document, at least both in my Ubuntu Dapper system and in wiki.x.org. Luckily, there is at least one manpage in freedesktop bug report, but that goes to debian only so far.

Configuration tool:: I really can’t understand why people were so happy using logitech_applet. I did try it (and in fact tried to tweak its Mandriva package as well). Yes, it found my mouse, but determined the mouse is a 2-button mouse without wheel! Feeling disgruntled, the next one I tried was lmctl, which was much, much better. At least it detects my mouse correctly, so I keep tweaking lmctl package, including borrowing patch from logitech_applet, and make it execute through udev. Later I give up because of change in udev and incompatibility between udev and my older kernel.

However, today I just rechecked the facts, and found that there is new effort called lomoco, which is a fork of lmctl. Not really sure if I can see it merged into Ubuntu universe, since version freeze has been in effect for long time already. Anyway, it has support for some newer mice like MX518, so probably it’s beneficial to go in despite the freeze.

OK, back to the docs. Indeed, some of the best references are still from www.linux-gamers.net (Mice and Keyboard section); the one from floam.sh.nu is also quite good though a bit aging. OTOH, there is another blog entry I really like, as it gives more detail about customizing buttons and browser (firefox) settings. And yet another blog entry suggests adding -no-jump-pointer -no-repeat -xsendevent options to xvkbd.

Anyway, all documents point to 2 critical tools: xvkbd and xbindkeys. Without them all the buttons beyond 7th one can’t be used, except for some particular window manager like openbox which can define custom mouse binding. And of course you might need xmodmap. However, for some unknown reason xvkbd and xbindkeys don’t provide robust performace for me during the old days (using Mandriva); they worked for a while, then completely stopped working as if they were stale, and refuse to work again unless I kill X window and relogin. Haven’t tried them again since I install Ubuntu; let’s see.

And it behaves quite strangely now when turning on/off cruise control. With the help of evtest, a little piece of code for evdev testing, I’m able to look up what happened during mouse clicks and wheel scrolls:

(These buttons are defined in linux/input.h.)

My point is not to question the bogus events before and after cruise control buttons, which are well known; the problem is, without cruise control, horizontal scrolling simply won’t work! Even xev remains quiet when the wheel is tilt — no event at all.

Yet with cruise control the bogus key events can’t be eliminated; there has been some hacky C code that remaps these button 11/12 events to wheel scroll, but I don’t like it.

For me at least both vertical and horizontal scrolling works fine in GNOME desktop (haven’t tested KDE), and in Firefox. That meets my basic need, and I’ll take some time to make the other buttons work later.

2008-01-26 Edit: The content above is outdated. Currently all such mice are intended to be supported via evdev. However, evdev makes this model of mouse even less functional than previous hacks, thus I already gave up using any extra buttons. Right now I always only use this mouse under Windows.