電池是滑鼠的「關鍵」
2008-01-26當年買 Logitech 的滑鼠回來,第一日裝 driver 時已經想笑了。原因如下圖(按圖放大):

看過今個星期 e-zone 的 Linux 友都一定會感到疑惑:為甚麼給 Ubuntu 的分數會那麼低的?說到外觀,不是有 Compiz 的嗎?明明裝了它後比 Vista 還要炫啊!(最起碼我已經有朋友這樣問過了。) 如果看完下面的理由後,就不難理解的了。
撇開三個平台本身不說,從短短訪問的數小時中,我覺得 Derek 的說話是最中肯的,因為三種平台他都玩過一下,有好說好,有壞說壞;Sammy 則有心借貶低別的系統來抬高 Vista,至少這是言談之中給我的感覺。對他來說,無論是哪一方面,Vista 都必定是最好的:
今天上 e-zone 做訪問,居然做出一些「賣國」的行為。身為 Linux 方面的代表,也加一把批評 Linux 的壞處;特別是硬件方面,令我不知所措。當然,是最新最新的 ATI display card 累事。Mac 和 Windows 明顯地沒有這方面的問題,缺乏硬件支援一向是 Linux 的死穴,今天正好打中要害 — default 的 Xorg driver 上不到 1680 × 1050 解像度,當使用 proprietary driver 後索性連 X Window 都掛掉。不用說,已經不需要示範 Compiz 了。幸好沒有裝進手提電腦,不然搞無線上網必定引致出洋相 × 2。
固然自己也有責任,沒有問個清楚明白,但這種和硬件死鬥的日子真是厭惡極了。
詳細過程已經在另一篇 blog 中說明。
今天看着整批人裝 SuSE Linux Enterprise 10,結果因為安排混亂,所有機器都沒試過,結果一塌糊塗。首先,是所有螢幕都是用最垃圾那款——Proview。如何垃圾?ddcprobe 的結果是,它支援的最高解像度是 290 × 210。結果是十居其九安裝完後沒畫面看——沒錯,十居其九,不是十成。有一個人好像在安裝界面中偵測多一次硬件,之後就能起動了。其餘的人改 X Window 設定,圖形界面勉強能用,但是那種字體就好像 2 pt 那樣,連英文字都看不見,所有文字僅能看到是一個個點排在一起。多數是 DPI 數值也搞錯了吧。結果是要跳過硬件設定才倖免於難。
另一個人更特別,用日文界面安裝,裝好之後當然就慘了——第一件事,鍵盤也變日文鍵盤配置,配合日常使用的美式鍵盤,當然是一團糟。另外,只有這個人安裝的 GNOME 怎麼也不能起動;但似乎不關日文的事。情況是,ALSA driver 無法載入,於是 Esound daemon 啟動不了;但這不是最精彩的部份。最精彩的是,沒有 Esound 的話 gnome-panel 就不能啟動,於是整個 GNOME 桌面都死掉!
最大問題的,不是這些東西,而是再生卡。我未有留意到再生卡在哪裏使用,這就觸礁了,還撞板撞得不輕。SuSE 安裝時,會使用硬碟的空位,但原來硬碟的「空格」根本是 Windows 分割區,靠再生卡 boot 起才會看到 Windows 分割區的!這樣安裝後會將硬碟中的 Windows boot sector 都蓋過,令 Windows 的 NTFS 結構盪然無存。後果是令 lab technician 加班兩個鐘,有點不好意思。當然,安裝教學的收場是死得很慘。
一張不貴的 Linksys 802.11G PC card,買了整整半年,初時滿心歡喜,買回來後才發覺怎樣也動不了,連卡也偵測不到,搞了一段時間,實在覺得太浪費光陰而丢到一旁去。昨晚下定決定拿出來再試一次,搞了一輪設定,終於能用了,同時也完全感受到 Linux 肯定只能夠成為 technical user 和 developer 的玩意,絕對沒可能為大眾接受,除非一些大公司指定買某款大廠的機種而且要預先安裝 Linux,但那也只是在商業環境使用而已,而且還要預先確定硬件才行。
無論別的軟件開發者怎樣努力,桌面做到能唱能跳,OpenOffice 能超越 M$ Office,也一樣沒用,因為頭號問題 — 硬件 — 一天不容易安裝,就永遠不能接近普通用家。我想像不到一個普通用戶如果能夠從一行(GUI 見不到的)error message 判斷出要下載某個特定的 command line 程式,將硬件的某個 driver 檔案截取其中的 firmware 出來放到某個特定的目錄之下。
從 day 1 開始,Linux 就不是為了接近大眾而存在的系統,而是給 technical user 一個學習的平台。怨氣太重了,不得不發洩一下,雖然我是自願做白老鼠,發生甚麼事也是自招的。就放長雙眼看看我的 Logitech laser mouse 何時能正確地使用所有按鈕吧,說不定這一天永遠不會來。現在的 evdev 對我來說和垃圾無異。
There has already been some negative comment about Ubuntu bundling non-free drivers, like nVidia, ATI and some wireless device firmware. For example, Pascal Terjan has written something about that, and surely Richard Stallman’s annotation on Ubuntu CD cover shouldn’t be forgotten as well.
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:
| Cruise Control On | Cruise Control Off | |
|---|---|---|
| Cruise Control upper button | 0×116[BTN_BACK] pressed Wheel up… 0×116[BTN_BACK] released |
0×116[BTN_BACK] pressed 0×116[BTN_BACK] released |
| Cruise Control lower button | 0×117[BTN_TASK] pressed Wheel down… 0×117[BTN_TASK] released |
0×117[BTN_TASK] pressed 0×117[BTN_TASK] released |
| Wheel tilt left | 0×118[?] pressed Horiz Wheel left… 0×118[?] released |
0×118[?] pressed 0×118[?] released |
| Wheel tilt right | 0×119[?] pressed Horiz Wheel right… 0×119[?] released |
0×119[?] pressed 0×119[?] released |
(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.