處理無release event熱鍵的新方法

Notebook的熱鍵(hotkey)常是由客製化過的EC(embedded controller) code來控制，而且沒有一個統一的標準，所以常常帶來了一些混亂。

熱鍵缺少了key release event就是很常見的情形。像是在Fujitsu Amilo和Samsung NC系列，很多型號都有這樣的問題。

因為沒有release event，所以會發生「只有第一次按有用」「只按一下降低音量的鍵，卻變成靜音」等奇怪的情況。

2.6.31之前的kernel會在AT keyboard驅動程式(atkbd.c)中加了許多DMI quirk和熱鍵的scan code，只要型號和scan code符合，atkbd會自動加入release event。

不過，在這麼一般的驅動程式中加入一堆DMI quirk，並不是一個好主意。所以在2.6.32 kernel，便在/sys下加入了一個可以由userspace控制的介面：

/sys/devices/platform/i8042/serio0/force_release

要讓某些scan code自動的產生出release event，只要把hotkey的scan code用逗號隔開，再寫入(echo + pipeline)這個檔案，之後kernel便會自動的幫這些scan code產生出release event。

對於一個distro來說，最好能夠收集這些有問題的型號和熱鍵的scan code，並且自動的偵測和設定。以Ubuntu而言，從Ubuntu Karmic之後，熱鍵便從HAL改為由udev來管理。所以在Ubuntu Lucid中，udev也加入了這個新功能：

將DMI quirk紀錄在此：

/lib/udev/rules.d/95-keyboard-force-release.rules

將熱鍵的scan code紀錄在此：

/lib/udev/keymaps/force-release/

在Ubuntu Lucid中，處理這類問題，就不須再更動、重編kernel，只要簡單的修改一些udev script即可。

top中數值的意義

us: user cpu time
sy: system cpu time
ni: user nice cpu time
id: idle cpu time
wa: io wait cpu time
hi: hardware irq (servicing hardware interrupts)
si: software irq (servicing software interrupts)
st: steal time (time in involuntary wait by virtual cpu while hypervisor is servicing another processor)

man vmstat
man mpstat

http://www.linuxquestions.org/questions/showthread.php?p=3541123#post3541123

為什麼用startx啟動X-window時 suspend會失敗

When login from the console, libpam-ck-connector will create XDG_SESSION_COOKIE. While you run `startx`, In /etc/X11/Xsession.d/90consolekit, it checks the environment variable XDG_SESSION_COOKIE is already set and will not create a proper CK session.

Try to `unset XDG_SESSION_COOKIE` before `startx` to see if suspend/hibernate works.

https://bugs.launchpad.net/bugs/415211

檢查kernel coding style

在linux kernel中的scripts/checkpatch.pl不只可以用來檢查patch的coding style，也可以用來檢查c source的coding style：

scripts/checkpatch.pl --file *.c

Linux熱鍵的除錯技巧(1)

筆記型電腦的熱鍵(hotkey)應該可以名列linux的常見問題之一。這裡所謂的熱鍵指得是像Fn+F1、Fn+F2，或是有些筆記型電腦會有專門調整音量大小…等特定功能的鍵。主要因為硬體上常常是各家廠商做各家的，並沒有一套共同的標準，所以每家廠商，甚至每個型號都要特別處理。

這也造成了在linux kernel原始碼中，有著像asus-laptop.c、thinkpad_acpi.c…等，這類專為各大廠不同型號的筆記型電腦處理熱鍵的module，而每個module中又有可能要對每個型號對不同的處理。除了這些modules，甚至連atkbd.c中都有很多的quirk，來處理各種型號筆記型電腦上的熱鍵(forced release key event)。

※

一種常見的情況是：當按下熱鍵時，既收不到scancode、也收不到ACPI event，看起來就像是linux kernel完全無法從硬體收到任何訊息。但是熱鍵在Windows中是可以用的，所以硬體是正常的。這種情況真是讓人完全找不到頭緒可以從何下手來debug。

不過這樣的bug其實還是有跡可循，我們可先猜測熱鍵是由embedded controller(EC)控制的，利用下列的方法來確認：

首先先找出EC的GPE編號：

$ dmesg | grep EC
ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62

看一下目前interrupt的數字：

$ cat /sys/firmware/acpi/interrupts/gpe11
10608 enabled

此時，按一下熱鍵，再看看interrupt的數字有無增加。如果interrupt的數字增加了，應該就可以判斷那個熱鍵是由EC控制的。

有時候EC也會送一些非熱鍵產生的interrupt，這就只能多靠眼力來觀察。

※

到這裡，我們就可以把責任歸咎於EC。因為理論上EC是必須要送出scancode或是ACPI event出來的。那麼EC又為什麼不送scancode或ACPI event出來呢？

在一些情況下，硬體製造商希望這個熱鍵的功能是必須安裝某個特定軟體才會啟動。像是某家廠牌的小筆電，必須對某個io port寫入一次，EC才會正確的送出某一個熱鍵的scancode出來。而這樣的「初始化」是寫在Windows平台上特定bundled的軟體中。Linux沒有這樣的軟體，所以熱鍵會無效。

此時我們可以回報原廠，請他們修改BIOS/EC code，讓熱鍵在Linux下也可以正常工作；如果我們知道EC初始化的方式(不過通常一般使用者不會知道)，也可以在某支驅動程式中來初始化EC。而另外的作法是寫一個驅動程式，透過kernel所提供的EC的介面來偵測EC的interrupt。

Mark Shuttleworth來Canonical台北分社

Lenovo Thinkpad X61 Bag of Bad Quality

I had an IBM X40 before. It was a really solid machine. I took it on my way commuting in my graduate school days. I did many works with it on the train.



So, when I need a new computer for my new job, I chose Lenovo X61. Thinkpad doesn't change over the years. Lenovo X61 is as good as IBM X40 (though the electric humming also remains). But it's not for the accessories.

The bag with Lenovo X61 tore after around a week's use.

I came to Lenovo Support Center in Taipei, but they told me that my bag has no warranty due to the lack of the invoice. I bought my X61 on a bidding site, so I didn't get the invoice for that. I also asked Targus, but was told that I had to contact Lenovo for the repair.

Finally, I could just find out my bag for X40 and abandoned the X61 one and don't know how to dispose the torn bag.