Freedom 硬體工程師研討會 - FHEC

近年來 Linux 在台灣資訊業的蓬勃發展，讓誰都不敢漠視這一塊市場，就連過去與微軟緊緊相結合的硬體廠，都開始『鬆口』和『鬆手』來支援 Linux 。資策會這次於11月 20、21 日舉辦了一個『Freedom 硬體工程師研討會 - Freedom Hardware Engineer Conference Taipei』，邀請了許多國外講者，演說內容包括了 Linux Driver 和相關硬體的開發，除了讓原有自由軟體開發者與相互交流外，也希望讓國內廠商能夠更了解，如何有效參與 Linux 硬體產品的開發。

話說議程內容還不錯，看到有個 ACPI EC driver 的 session，眼睛都亮起來了。個人希望各個廠商能夠多了解這議題，不要再隨便脫口就說：『因為在 Windows 上正常，所以都是 Linux 的問題』。與 Linux 的開發者共同解決才是正確之道，在未來也能夠更省時省力，也或許可以共同促使 BIOS 廠多擔起一點責任。

心內真心的吶喊：對 Linux 的開發者來說，現在實在是太辛苦了。

Linux Kernel Patch: Suspend/Resume 以後無法 Restart

最近碰到個難解的問題，就是系統無法 Restart 的 Bug，有 usplash 的人會卡死在關機畫面，在 console 底下，會停在 kernel 吐的最後一行訊息：『Restarting system』。有趣的是，這 bug 只會在 suspend/resume 之後才發生。沒錯，這應該是 ACPI 的 Bug ，但其實可以透過 Patch Kernel 來修正。

這 patch 可由此下載：linux-kernel-restart.patch

後記

因為 BIOS 的人永遠不承認是自己的錯，我們只好自己動手。

在霧裡欣賞 BIOS 裡的 ACPI Description Table

ACPI(Advanced Configuration & Power Interface) 是近年來廣泛被使用的電源和硬體狀態控制標準，在 PC 產業中已經被用來取代 APM(Advanced Power Management)，並做為一個電源控制的首選規範。截至本文為止， ACPI 的最新版本號是 3.0a，詳細說明資料可參閱官方網站（http://www.acpi.info/）。

常聽一些人解釋說：『因為休眠、暫停功能在 WindowsXP 系統上沒問題，所以 BIOS 在 ACPI 的處理上應該正確無誤。要是在 Linux 等其他系統上出現問題，那一定是其它作業系統的錯。』

乍聽之下，這樣的解釋真的很合理，完美的證明了 BIOS 沒有問題，但實際上，這樣的說法就好像賣藥郎中說：『這藥強健筋骨、治百病，男人可壯陽，女人可改善體質，絕對百利而無一害，要是服用後病沒好，仍然一厥不振，且頭暈目炫、口吐白沫，那肯定是你身體有問題，虛不受補。藥，肯定是沒問題的。』

要窺探並破解 ACPI 的迷思，我們可以直接檢查存在於 BIOS 裡的 ACPI Source ，了解到底發生了什麼事，會讓 ACPI 功能在不同系統上有不同的表現，雖然會有如霧裡看花，但沒關係，反正世上最美的事物就是最矇矓的恐龍呀:P。如果是在 Linux 系統下，我們可以很輕易的將 ACPI 的 DSDT(Differentiated System Description Table) 給 Dump 下來：

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

『dsdt.aml』是一個 Binary 的 ACPI Machine Language 檔，我們可以使用 isal (Intel ACPI Source Language compiler/decompiler)將它 disassemble，若是在 Debian/Ubuntu 之下，可直接用 apt-get 安裝該工具：

apt-get install iasl

然後使用 iasl 直接 disassemble dsdt.aml：

iasl -d dsdt.aml

完成後會產生一個人類看得懂的『dsdt.dsl』，該檔是用 ACPI Source Language 寫成，我們可以用 vim 等文字編輯器開啟瀏覽。你可以搜尋關鍵字『Linux』，會發現有用來判斷作業系統的相關描述：

If (MCTH (_OS, "Linux"))
{
             Store (0x03, OSVR)
}

你也許會看到更多有關於 Microsoft Windows 的描述：

If (_OSI ("Windows 2001.1 SP1"))
{
             Store (Zero, OSVR)
}

這意味著，ACPI 會依照不同作業系統而有不同的行為，可能有些功能在 Linux 下就會被關掉，亦或是因為會對記憶體位址做特殊存取，雖不會造成 Windows 任何影響，但卻可能剛好破壞掉 Linux Kernel 的運作，導致 boot/reboot 或 S3/S4 時會 hangs 或 crash。有時候缺少正確的 Return 值，也會造成 S3/S4 resume 的失敗。以下就是一個實際缺少 Return 導致 resume 不正常的例子，但我自行修正並補上正確的回傳值：

Method (_WAK, 1, NotSerialized)
{
             ...
             ...
             Return(Package(0x02){0x00, 0x00})
}

如此遺漏而產生出來的 ACPI bugs 有非常多，在此也不便一一列舉，日後有時間再慢慢彙出來。不過，既然我們已經得到 DSDT，意味著只要有心，都可在此改寫並修正一些 ACPI 的問題。雖然我們並不能將修正過後的 DSDT 寫回 BIOS，但 Linux Kernel 編譯時若有開啟『CONFIG_ACPI_CUSTOM_DSDT』，就可以使用自定的 DSDT 取代原本機器上的 table，只要將檔案放到 /boot 下即可（在 Debian Lenny/Sid 上的 Kernel 似乎沒有開啟這項功能）。

將改好的 dsdt.dsl 重新 compile：

iasl -tc dsdt.dsl

此外若你是在 Ubuntu 下，請直接將編譯好的 dsdt.aml 放到 /etc/initramfs-tools 之下，再 update initrd：

sudo update-initramfs -c -k all

然後重開機後，便可使用自訂的 DSDT 來控制 ACPI 的行為。

至於更多的 ACPI Spec 細節，可直接下載 spec 文件：

http://www.acpi.info/spec.htm

亦或是可參考 isal 工具的官方資料：

http://developer.intel.com/technology/iapc/acpi/

Fred's blog 週年

自去年轉移 blog 到這開始，周遭陸陸續續發生不少趣事和惡事，彷彿老天突然給我一張不能拒絕的三溫暖門票。如今近一週年，回顧，這大概是活了二十幾年以來，心理變化最大、波形最不穩定的一年，因此，臭味相投的朋友結交不少，不小心得罪的人也不在少數。不管各位看官是屬於哪一種，還請多多包涵。

近來為五斗米而連日忙錄，前陣子更是平均每日睡不到 2 小時，整個 blog 都沒時間可以添些新東西，深感對自己的要求就此停擺許久。仍記得過去，每當找不到題材來撰寫新文章，就知道自己的水已經漏光，該是要更努力充實和思考新事物。也就是如此，寫 blog 有時就像有人默默的在背後推一把，強迫自己不停地去鑽研或體會更多美好的經驗。若失去寫文章的行為，頓時便會感覺到自己在原地踏步。

值得慶賀的是，這樣特別的一年可不是每個人都有機會去體驗，相信再渡過了這最後的艱苦期，應該就會開始平順些，也可以重新再度威脅自己寫些新東西。

後記
被工作雜務逼得太緊，有時候腦袋都不會轉了，常常一些簡單的程式和問題，想破頭也想不通也解決不了，真的是變傻了。

淺談 Hacking LXDE 簡報上線

於 Tossug 心得分享的《淺談 Hacking LXDE 》簡報上線，歡迎各界多多指教。

Hacking_LXDE.pdf

* 更多細節請參閱舊文章《讓我們輕鬆自在設計自己的 LXPanel Plugin》

Tossug 心得分享 - 淺談 Hacking LXDE

有幸受邀，將在今天（2008/10/7）晚上七點半，在 Tossug 聚會活動給予一場簡單的技術心得分享，主題是《Hacking LXDE》。今天將會談到 LXDE 為何會輕量、快速，並簡略說明其技術細節。也會提到「如何開發 LXPanel 的 Plugin」，並用一個簡單的實例解說。

地點在捷運「士林站」的《流浪觀點》，活動場地的詳細資料：

流浪觀點是一家靠近士林捷運站得咖啡店，提供餐點咖啡投影機及不定期紀錄片選映。
地址：台北市士林區福壽街13號
電話：02 28382619
士林捷運站一號出口，直走過馬路(中正路236巷)，沿公園靠右，見流浪觀點招牌即是 

Why so serious? 不正經的重新包裝 deb

要好好的包個 Debian package 其實是一件大工程，除了注意事項能彙整成冊之外，如何好好設定 package 的相依性和說明文件更是一個不小的挑戰。所以，一個包得差勁的 Debian package，很有可能造成系統大亂，甚至讓系統承受不必要的額外負擔，這就是為什麼 Debian Maintainer 們會如此受人敬重的原因。

不過有的時候，我們並沒有要維護一個 project ，也沒有要上傳一個 package 到嚴肅的 Debian official repos，只是純粹想惡搞或是貪圖方便而包一個自用的 deb。我們也許不用、也不想顧慮太多細節，因為可能只是簡單的將現有的 package 拆開，加入幾個自定的檔案再包回去。這樣的需求，大致上可以這樣做：

# 建立一個新資料夾
mkdir mydeb
# 解開 package 的 DEBIAN 控制文件到新資料夾的 DEBIAN
dpkg-deb -e mydeb.deb mydeb/DEBIAN
# 解開 package 的檔案到新資料夾
dpkg-deb -x mydev.deb mydeb
# 處理或惡搞完成以後再次包裝起來
dpkg-deb -b mydeb mydeb_new.deb

這樣修改和包裝 deb 非常的不正規，品質上也不合格，不過既然包出來的 package 只是自己私下用用，Why so serious?