Fred's blog

最近接了一個小案子，主要是協助客戶將 Qt 應用程式從舊板子移植到新的硬體上，由於硬體是 Third-party 做，當然所有的驅動程式也是由別人處理，我們並不經手，只和硬體廠商密切合作。 這次我們碰到了一些 Keyboard 問題，一開始是 Linux driver 缺少 input_sync() 的操作，導致 Qt 無法正確辯別按鍵的『壓放』。接著碰到個更棘手的問題，就是 Qt 送到應用程式的 Key 事件（Event）有很大機率會送錯。這將導致按鍵所觸發的結果，有很大的機會我們無法預期。檢查過 evdev event 和其發出來的 keycode，我們確定了 Linux Driver 是正確的，判斷應該是 Qt 的問題。 經過一番檢查後，發現是因為 Qt-Embedded 預設使用 TTY Driver(qkbdtty) 去驅動鍵盤，大部份情況下不太會有問題，但因為我們走的是標準的 Linux evdev (/dev/input/eventX)，如果很快速或多重觸發鍵盤按鍵，就有可能讓 Qt 的 TTY Driver 取樣和解析出錯誤的 Event 值。最快的解決辦法就是捨棄 Qt TTY Driver，然後改用 Qt  LinuxInput Driver(qkbdlinuxinput)。 不過 qkbdlinuxinput 並不處理 VT，這是與 qkbdtty 最大的差異，此舉會造成板子上的 Console 不正常切換，Debug 用的 Console 會因此壞掉。筆者在此對 QWS Keyboard Driver 做了些修改，讓 tty driver 使用 linuxinput driver 的方式去解析 keyboard event，並保留 VT 的處理機制。 Patch 檔案連結如下： http://fred-opensource.googlecode.com/git/patches/qkbdtty_qws.patch

為了注音輸入法，您是否長久以來也仍在使用 SCIM？每次裝好 Linux 的第一件事就是刪除系統預設輸入法，我們彷彿是外星人一般，一點都沒享有人權。感謝 OSDC.tw 2011（活動期間 3/26 ~ 3/27） 提供好吃的食物和舒適的場地，在活動這兩天筆者花了一點功夫做 patch，修掉了 ibus-chewing 單純注音模式的一些 Bugs，現在基本上 ibus-chewing 單純注音模式已經可用，我們可以丟掉 SCIM + 爛注音 Table 了！ 以下是 Lightening Talk 的簡報檔： 後記 由於簡報格式的關係，暫時無法轉成 PDF 輸入，所以目前使用錄影的方式公開，待轉檔程式開發完成再來釋出 PDF 檔。

As you know, Apple iPad is the latest craze and brings back tablet PC marketing cause most manufactories aim to begin to produce products with touchscreen. In order to make applications work with touchscreen for tablet PC, implementing on-screen keyboard is the major issue. There are many open source solutions you can get from internet, but you may get a question, what time is better to start the on-screen keyboard? It is a good idea that enable on-screen keyboard when input box get focus, that is just like Apple iPhone, iPod, iPad and a lot smart phone. SCIM has panel support, it can provide on-screen keyboard. So I have patched scim-bridge to support that auto enable input method when getting keyboard focus for a GTK+ text entry. If so input method is enabled, SCIM will show on-screen keyboard automatically. Here is my patch you can get: http://people.linux.org.tw/~fred/patches/scim-bridge-0.4.16_client-gtk-autoshow.patch

As you know, I've done Android Eclair porting for Devkit8000 in the past, which is based on Embinux. It's a experimental work for passing time, I have no time to maintain and fix bugs friends reported after that. However, I think it is not good because the result will be getting lost as time goes by. 0xdroid is another Android distribution which is different from Embinux, its developer  Jim Huang(jserv)  who has contacted me a few months ago, and he hope that I can try porting 0xdroid on the Devkit8000. Actually, I am glad to make 0xdroid takes over my work, it is the best result for me. Currently, I've done most works, 0xdroid can run on Devkit8000 with success. And also, My patches have been committed to 0xlab-devel mailing list. Because I have another platform SBC8100 which is also produced by Embest, I've done works on that as well. You can see my patches from 0xlab-devel mailing list, or you can visit my website to download it directly: http://people.lin...

If you would like to make Android work on Devkit8000, you can follow to patch your kernel which is mentioned in my old article( Android Eclair Porting for Devkit8000 ). After that you might notice the touchscreen doesn't work, it is a ads7846 kernel driver bug from Embinux. So I modified a few lines of code to fix the bug. Here is the patch: http://people.linux.org.tw/~fred/patches/devkit8000-touchscreen-android-kernel.patch

It's not only for fun! Porting Android is a great practice for me as well. Devkit8000 is a clone of OMAP3 Beagle(Beagleboard), so we can found many porting informations of Beagleboard from internet. It's helpful for us, we only need to deal with a few places which are some differences between Devkit8000 and Beagleboard. Google Android Eclair is working well on the Devkit8000 board now after I tried to port it last weekend. Here is the patch: http://people.linux.org.tw/~fred/patches/devkit8000-android-kernel.patch Based on Embinux , I added the Devkit8000 support, which includes: OMAP DSS Driver for display 4.3 inch LCD Panel support (480x272 60Hz) 7 inch LCD Panel support (800x480 60Hz) Touchscreen ADS7846 support Sound Codec (TWL4030) Keypad (TWL4030) Ethernet Device support (DM9000) Kernel Config for Android Compile Kernel with Devkit8000 kernel config: make omap3_devkit8000_android_defconfig make CROSS_COMPILE=arm-linux-gnueabi- uImage Kernel Comman...

目前，無論是 Linux Kernel 內的 PenMount Touchscreen Module 或是 Xorg 下的 Driver，都無法支援新版的 PenMount 6000，在官方網站上也只有提供 Xorg 的 binary driver，而且並未開放原始碼。日前因某些案子需要在 kdrive 上驅動 PenMount 6000，就自行 Hack 並寫了一支粗糙的 Driver。由於在 kdrive 上的 touchscreen solution 都是藉由 tslib 來實作，所以這支 driver 是一個 tslib 的 plugin。 一個意外發現，kdrive 底下的 Xvesa 並未支援 tslib，所以就算在 configure 下 enable tslib，雖然相關的 function 會被編進去，但卻不會真正被註冊在 driver list 上。對此，也在這寫了一個小 patch 以解決這問題。 驅動程式原始碼和 Xvesa patch 可在這取得： http://people.linux.org.tw/~fred/drivers/pm6000_tslib.tgz 將編好的 pm6000.so 放到 plugin 指定目錄後，然後再將 tslib config file 的 module_raw 設定成 pm6000，就可直接用下列方法使 Xvesa 驅動 PenMount 6000 Touchscreen： Xvesa -mouse tslib,,device=/dev/input/eventX

If you have the Thinkpad T60 laptop, maybe you will have a problem - ethernet device doesn't work. With command "dmesg", we can get some error messages that is just like: 0000:02:00.0: The NVM Checksum Is Not Valid ACPI: PCI interrupt for device 0000:02:00.0 disabled e1000e: probe of 0000:02:00.0 failed with error -5 It means the contents of EEPROM on the ethernet device was broken, because the checksum is not valid. For all I know, so many Thinkpad T60 laptops has the problem cause e1000e or e1000 driver return the error message and the device doesn't work. Here is a patch to add a parameter - "eeprom_bad_csum_allow" for the e1000e kernel driver: e1000e-allow_eeprom_bad_checksums.patch To enable the option will lead e1000e driver to ignore checking checksums of EEPROM. So you can use the command to load the e1000e driver be patched to enable your ethernet device: sudo modprobe e1000e eeprom_bad_csum_allow=1 BTW, I think you might see the similar patch for e...

最近碰到個難解的問題 ，就是系統無法 Restart 的 Bug ，有 usplash 的人會卡死在關機畫面 ，在 console 底下 ，會停在 kernel 吐的最後一行訊息： 『 Restarting system 』。有趣的是 ，這 bug 只會在 suspend/resume 之後才發生 。沒錯 ，這應該是 ACPI 的 Bug ，但其實可以透過 Patch Kernel 來修正 。 這 patch 可由此下載： linux-kernel-restart.patch 後記 因為 BIOS 的人永遠不承認是自己的錯 ，我們只好自己動手 。

到了今天，SMP系統已經很常見，街上隨便抓一台 NB 都是雙核心的架構。但也因為是 NB，又常搭配 NVIDIA 的顯示晶片，我們必須對 idle method 做適當的調度，以保持其穩定性和續航力。在過去，我們在開機就必須指定 BootPrompt 以決定 idle method，這對 LiveCD 和各 Linux 套件實在不是很好，因為在 Boot Loader 時，我們並不曉得該台電腦的狀況，無法判斷是否該用 poll idle 的方式啟動 Kernel。 因此，我針對這問題對 Linux Kernel 做了一個 patch ，讓用戶可以在進入作業環境後，從 /proc/sys/kernel/ 中即時開關 poll_idle()，以便硬體偵測程式可以依系統需求，動態去啟動 poll_idle()。 這次的 patch 可由此下載： linux-kernel-2.6.23.9-idle_poll_sysctl.patch

電腦的演進神速，轉眼就到了 3D Desktop 的時代。雖然許多人追求輕便型的桌面環境，但如果不嘗嘗 CompizFusion 所帶來的超酷視覺享受，似乎對不太起今日的電腦硬體 :P 這幾天發現 lxpanel 和 compiz cube 有相容性的問題，也就是 viewport 不會跟著 active 的視窗轉動。這問題牽涉到 EWMH 規範的操作，簡單修正後 lxpanel 的 taskbar 已經能正常切換工作並更改 viewport 狀態。 想修正的人可以使用這 patch： lxpanel-0.2.4-viewport.patch

關於 oxim 的 xevent 處理機制所造成的 bug 在前一次 patch 時已經提過﹝請參閱『 oxim Patch: Event BUG 』﹞，由於網友 swyear 的告知，也意外的發現在 openSUSE 10.3 上有相同原因所造成的困擾。 經過這兩天測試後，發現前一次的 patch 雖然解決了無法正常啟動 oxim 的問題，但是其運作的並不穩定，有死掉、呆掉的情況發生，而且造成的 CPU 負擔甚大。所以，這次用 select 更進一步改善了 oxim 對 X event 的處理機制。 關於這次的 patch： oxim-1.1.3-xevent-20071223.patch

最近移植 oxim 時碰到一個問題，就是當我使用 xinit 啟動 X Server 和 oxim 時，oxim 會 wait 在那動都不動，使用 strace 也無法 debug，因為一旦以 strace oxim 這樣的方式啟動 oxim，它就沒這個問題。﹝什麼！？這 Bug 還會自動躲 debug 程式！﹞ 一邊努力 debug 一邊在 IRC 上抱怨，最後終於靠 jserv 的建議與指導之下，用了 gdb + XSynchronize() 找出了出問題的地方，果然皇天不負苦心人啊！ 問題出在 oxim 對 gui event 的處理，大概是使用 xinit 直接啟動的環境太簡單乾淨，oxim 的 Trayicon 等需要 GUI 的部份完全收不到 X 的 event，所以就停在 XNextEvent 苦命等待。 不過就在解決掉 event 等待的問題後，我將 debug 時用的 XSynchronize() 移除，隨即碰到的就是 GUI 重繪問題。雖然 oxim 順利的啟動了，但選字區、選單都一片空白，將 XSynchronize 開啟就正常，這點非常怪異令我不得其解，不過想到 oxim 只是處理使用者輸入中文，對 graphic 的處理速度並不非常要求，所以我將 XSynchronize 保留。 關於這次的小修正，我已經做成 patch： oxim-1.1.3-xevent.patch