UDS-M落幕

Ubuntu 10.04 (Lucid Lynx)才剛發表，Canonical和Ubuntu社群又開始忙著準備下一個版本的開發。首先就是5月10日到14日在比利時布魯塞爾召開的UDS-M (Ubuntu Developer Summit for Maverick)。

在這一星期中，會有滿滿的議程用來討論下一版Ubuntu的藍圖(bluesprints)，而討論完成的bluesprints會成為下一版Ubuntu的工作項目，會被持續的追踪進度。 :-)

對於kernel team而言，Jeremy Kerr關於device tree的session十分有趣：Device Tree Overview，ALSA System on Chip (SoC) Flattened Device Tree Bindings和Using Device Tree on ARM。

顯示Canonical是很重視ARM的這塊市場的（如新成立的Linaro，Canonical也有參與）。

Canonical Kernel Team / 攝影者 Acelan

同時UDS也是Ubuntu開發者和社群間彼此討論、交換心得的一個機會，不只是可以和大廳走廊遇到的開發者閒聊，而是有一大堆的community team的session可以參加。只是可惜從沒遇到來自台灣的與會者。希望在下一次UDS-N可以遇到來自台灣社群的人參加。

如果你仔細看UDS的議程的話，會發現這是一個十分忙碌的一週，從早到晚的session、再加上時差、還有語言的隔閡、還要思考，更別提近20小時的飛行時間，每次回來都像是全身精力被抽光的狀態。

不過UDS的確是十分有生產力的一週，下一版Ubuntu的骨架都在這一週內被討論和決定。

處理無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台北分社