2007年6月29日星期五

OLPC Hacking Meet-up心得

經過十天的等待,於於完成了這次「OLPC Hack Meet-Up Day」的活動。活動期間,感謝jollen、jserv、PingYeh、 Andrew、...等人提供不少對活動的經驗和建議。這段期間也感謝BV1AL、KC、olv、 FourDollars、linanne、aguai、wesley、thinker、yungyuc、gaso、yuren...等人的幫忙,才能順利將活動完成。

活動開始,先是由Mat簡單介紹一下如何用QEMU模擬OLPC和測試程式。之後則是共同開發和交流討論。21:10-22:00 則是展示時間,首先是jserv展示了QEMU用於模擬系統開發的各個應用,也現場展示了他最新的成果「親手打造Tablet / WebPad」。接著,FourDollars也跟著和大家分享影音串流程式最新的發展,分析未來的驅勢。並同時展示了一個他參考pcman的程式而改出來的影音外掛程式。可以非常方便的點選網路廣播並收聽,並發想也能整合進OLPC,提高OLPC的娛樂性。

而在PCMan on OLPC這個主題上,由國內開發LiveCD(USB)系列的BV1AL將gcinOLPC上的成果作成LiveCD的映像檔,並設定好網路等相關部分。而PCMan X開發團隊的字型好手olv ,則是解決OLPCPCMan X中文字型顯示的問題。在經過一段時間修改,順利將兩方的成果結合起來,如下:

雖然還是有許多小缺點,但這張快照也象徵了我們用行動來實踐我們的信念,也呼應了活動發起的訴求。

在活動期間,wesley、aguai、annelin... 也嘗試利用QEMU建立多個OLPC來模擬mesh network的測試環境。而Andrew、PingYeh、BV1AL、...在Tick偶然拿到OLPC實機的root console後,也著手研究了OLPC的系統更新、開機流程,相信不久之後也能見到相關的經驗分享。

最後希望能持續將這些成果整理出來,以開放的方式回饋給upstream和社群。

2007年6月28日星期四

親手打造Tablet / WebPad

從事嵌入式系統開發,很大層面就是想體會「親手打造」的成就感。以往最大的問題就是進入的門檻較高,不僅得有開發硬體,還得要耗費大量的時間進行驗證測試,然而,這些繁瑣的過程會讓我們失焦,是的,最重要的部份,還是賦予硬體生命的軟體,這才是具備長遠價值的產物,一旦有了足夠的經驗與系統軟體,要在相容的硬體移植或加強功能設計,那就如魚得水了。

之前選定一個用以「練功」的題目「構想:Embedded Linux + Mozilla」,作法可有很多種,不過筆者嘗試以系統模擬的途徑,驗證「視覺化系統模擬與偵錯」一文中提出的概念:引入針對嵌入式裝置的基礎建設,作以system prototype、進階分析,以及快速軟體開發之用。上個月則於討論群組提出具體的想法「RFC: Tablet/WebPad 參考設計」,目前已稍有成果,在Google Code Hosting上申請了新專案「mind - MIND stands for "Mind Is Not a Device"」,可透過OpenEmbedded的迷你子集合去建構整個Embedded Linux作業系統,並調整為Tablet / WebPad的系統組態,以Xscale與x86作為參考開發的硬體平台,本階段已可使用Qemu為基礎的系統模擬進行驗證 (GNU Toolchain、Emulator,與Debugger均移植到Win32),以下是運作中的展示畫面:

這呈現了我們Embedded Linux平台的應用程式,即精簡版的Mozilla web browser,輔以XUL打造進階的使用者介面。這個系統主要是作概念性呈現,所以其他應用程式則相對單純,程式主畫面如下:
待作事項:
  • 針對ARM平台規範新的虛擬硬體組態,加入Wifi / Bluetooth裝置模擬
  • 加入網路管理程式,如Linetconf
  • 透過內建的OProfile進行深入的效能調校
  • 提供x86 LiveCD

2007年6月27日星期三

在Ubuntu / Debian上啟動kqemu加速OLPC的執行

Mat 已經寫了一篇簡單的文件「Hello World for OLPC」,只要照著做就可以很容易的把 OLPC 利用 qemu 模擬跑起來了。不過如果可以先把kqemu的kernel module裝起來的話,那麼執行OLPC的模擬會更加的快速順暢。以下簡單介紹Debian/Ubuntu上啟動kqemu的方法:

1. 首先把相關的套件裝好

# sudo aptitude install module-assistant
2. 然後利用module-assistant編譯出kqemu的kernel module並且安裝到系統中
# sudo module-assistant auto-install kqemu-source
3. 最後載入模組並建立裝置節點
# sudo modprobe kqemu major=250
# sudo mknod /dev/kqemu c 250 0
# sudo chmod 666 /dev/kqemu
然後就可以照著Mat寫的文件跟著做即可。

另外~ 目前OLPC底層的作業系統是Fedora Core 6 (zod),所以啦,知道FC6怎麼玩的,基本上OLPC也是一樣地玩。

2007年6月25日星期一

模擬Linux on Palm 5

Palm產品家族自第五代開始,部份採用Intel Xscale處理器,日前qemu的CVS tree也正式納入支援,於是熱血的hackers又開始鑽研是否可模擬Palm 5的硬體,並在其上運作Linux。在一番嘗試後,Alex很高興跟大家宣佈這個訊息,請見「Testing Linux4Palm on qemu」一文。他在 Hack&Dev計畫 (目標即是將Linux移植到原本運作PalmOS的硬體環境) 的程式碼加入以qemu為基礎的Palm 5的硬體模擬器,目前支援的硬體列表如下:

  • palmtc - Palm Tungsten|C (PXA255)
  • palmz72 - Palm Zire72 (PXA270)
  • palmtx - Palm TX (PXA270)
  • palmld - Palm LifeDrive (PXA270)
取得與編譯方式如下:
# svn co https://hackndev.svn.sourceforge.net/svnroot/hackndev/qemu/trunk qemu-hnd
# cd qemu-hnd
# ./configure --target-list=arm-softmmu --cc=gcc-3.4
# make -j2
預先取得必要的核心與檔案系統影像檔,假設解開壓縮檔後位於./palm/0.0.3-fnw目錄,則可透過以下方式執行: (其中一個hardware model)
$ cat RUN.sh
#!/bin/sh
BASE_DIR=`pwd`/palm/0.0.3-fnw
./arm-softmmu/qemu-system-arm \
-M palmld \
-kernel $BASE_DIR/zImage \
-sd $BASE_DIR/Angstrom-opie-image-palmld-0.0.3-alpha.rootfs.ext2 \
-append "root=/dev/mmcblk0 psplash=false"
啟動畫面如下:
過程中可透過qemu作LCD panel與終端機顯示 (serial) 的切換,也就是 Ctrl-Alt-[13]。以下是終端機操作畫面:
系統模擬越來越多元了。

2007年6月21日星期四

Hello World for OLPC

許多朋友好奇前天的螢幕快照怎麼來的,其實過程並沒有想像中的那麼難。小弟就以作一個Hello World的程式作範例。

在開始之前,先假設你手邊已俱備下列幾個主要的工具:

  • QEMU i386 ( OLPC的平台是x86 )

操作步驟如下:

1. 首先取得OLPC的映像檔:按這裡下載

2. 啟動qemu
qemu -redir tcp:2222::22 olpc-redhat-stream-development-devel_ext3.img
其中 "-redir tcp:2222::22"的意思是將 QEMU中的OLPC的:22 Port和本機端的:2222 Port接在一起。

3. 取得終端機

進入到OLPC視窗環境後,在OLPC的模擬環境按 “
Ctrl-Alt-3”,就會進到console模式(要回到視窗模式請按 “Ctrl-Alt-1” )。接著用root登入(預設沒有密碼),就可以順利取得root console。記得順便設定一下root的密碼

4. 下一步?

根據官網上的說明,下一步應該就可以直接連線進去,但是實際上卻不行,為什麼呢?因為這時候的OLPC還沒有將網路啟動,需要先設定網路才行。

5. 設定網路

在root console下執行
ifup eth0
或是
echo ifup eth0 >> /etc/rc.local
設成下次自動啟動

6. 確定啟動sshd
/etc/init.d/sshd start
執行到這裡,我們已經有能力可以連線到QEMU中的OLPC了。

7. 連線到OLPC
ssh -X -o NoHostAuthenticationForLocalhost=yes -p 2222 root@localhost
其中 "-X" 是設定視窗轉送的參數。(可以執行xterm看看,所產生的視窗會將送到本機端來)。進行到這裡,我們已經有操控整個OLPC系統的能力,可以像使用一般Linux的方式去使用。

8. 如何作一個最簡單的Hello World?

目前OLPC並沒有內建gcc等開發工具。不過uname一下,可以發現OLPC的平台是i686。也就是說,我們可以先在本機端開發好程式,編譯好了再上傳執行即可。

而在OLPC裡的視窗程式執行環境為gtk、pygtk。我們不妨利用現在的pygtk來作為試驗。在這裡我們就直接引用pygtk給的官方範例

9. 如何上傳?

最直接的方式就是透過scp的方式上傳。
scp -o NoHostAuthenticationForLocalhost=yes -P 2222 ./helloworld.py \ root@localhost:/home/olpc/hello_world.py
10. 如何執行:

由於OLPC的XWindow是用olpc這個使用者的身份執行。所以在執行前記得切換成olpc這個使用者
su - olpc
之後用視窗轉送的方式來執行
DISPLAY=:0.0 ./helloworld.py
就可以看到簡單的Hello World的畫面了

2007年6月20日星期三

多國語言支援的圖形化kboot

上週二 (Jun 12) 在TOSSUG聚會活動「2007 年第 7 場心得分享 - 組字的核心:字的結構」時,展示「Xorz/Embedded的動態組字實做」並提及可能的應用形式,我舉了關於boot loader的例子,作為說明動態組字技術在嵌入式系統的重要性。的確,隨著虛擬化技術與能源管理技術的突破,boot loader越來越多元,針對前者,得配合virtualization executive做出不同的啟動程序,而對後者來說,動態進階能源管理所建立的「中間資訊」(suspend to RAM / suspend to Disk),也需要作合理的處理,這都需要高度彈性的boot loader涉入。另外,我們可從DSLinux (port Linux to the Nintendo DS gaming console) 與PS3 Linux (SONY PlayStation 3的Linux移植) 等計畫發現,其移植的途徑不同以往,而是大膽採用kboot/kexec的機制來降低移植的難度,並提供多樣的應用方式,詳情可參考之前的文章「kboot初探與模擬驗證」。

早上在hack OLPC時,又想到上述議題,所以我決定作個概念性驗證的實做,驗證kboot這個「功能強大的Linux boot loader」對OLPC的影響。以往的boot loader雖然實做了圖形介面,但功能是很侷限的,頂多只能產生靜態選單與底圖,筆者的想法就是,用一個簡單的圖形系統取而代之,提供真正有彈性的使用者互動機制,而我們有Xorz/Embedded。另外一個議題是,我們應該允許不同的開機方式,比方說透過網路或USB隨身碟,而且可在任何時間切換,使用情境很直覺,可以假設一開始運作缺乏中文系統的OLPC預設Sugar UI,等有需要的時候,插入USB隨身碟,系統會彈出一個boot畫面,提示使用者是否要重新開機,因為透過kexec系統呼叫,這一切將會非常快速 (跳過BIOS與硬體初始化),而USB隨身碟上面的系統當然就可以有中文或者其他客制化的環境。

同時,筆者也想藉此彰顯在「組字技術與手持式裝置的新機會」一文表達的想法,為何我們千方百計想把CJK (中日韓) 語文整合到嵌入式系統設計呢?或許我們會犧牲美觀,但是可帶來對於多國語文最基本的顯示能力,這大可整合到boot loader或kernel中。聽起來很玄,俗語說:「一圖勝千言」,看看現在的進度:
以上呈現的想法就是動態讀取裝置列表 (透過udev與FreeDesktop HAL),讓OLPC的軟體建設得以作基本的probing處理,進而在小型的圖形環境中產生對應的動態選單與動作描述。圖片展示了讀取USB Disk,並取出其中的中文標籤,以選單方式讓使用者決定系統的啟動與否,甚至,我們可透過網路來啟動或更新整個OLPC,這一切將可相當有彈性。

附帶一提,右下角的圖示就是「OrzLab的吉祥物」:「囧囧」,正準備跳出傳統的PC,走向多種嵌入式系統裝置的新應用。

OLPC Hack Meet-Up Day

Mat稍早寫了「PCManX on OLPC」一文,提到他最近對OLPC所作的修改,並試圖移植知名的BBS連線程式PCManX到該平台上,不過礙於OLPC底層未能提供足夠的基礎建設,所以Mat發起一個活動「OLPCHackMeetUp」,邀請更多同好齊聚hacking。以下引述介紹文字:

== 活動宗旨 ==
國際知名的OLPC(One Latop Per Child,百元電腦)計劃正在進行,硬體製造的業務也由國內的廣達代工。然而國內社群對OLPC相關的知識並不多,軟體方面也參與的很少。 因此希望能藉著發起這個活動,引介自由軟體愛好者實際參與OLPC的軟體開發,同時能互相交流軟體開發的經驗和心得,並以開放的方式回饋給OLPC計劃與自由軟體社群。

== 活動目標 ==
在目標的選定上,我們希望能以一個近程目標來秀出我們的特有的特色軟體。於是我們選定開放的BBS軟體PCManX作為目標,同時也希望能在實作過程中,找出OLPC的中文支援的方法:

  • PCManX放進OLPC環境執行,並調整成符合Sugar (OLPC的外觀風格) 的應用程式風格
  • 實作glibc locale + Fontconfig data + TTF + SCIM以提供中文顯示、輸入環境

時間預定於June 28, 2007 (四),晚間19:00~22:00舉辦,歡迎參與OrzLab的討論「OLPC Hack Meet-Up Day」。至少有以下議題需要思考:

  • 輸入法的型態:傳統的GTK+ IM module或Ajax web IM
  • OLPC的軟體開發方式與模擬器的整合
  • 底層i18/L10n基礎建設

期待您的參與及指教!

2007年6月18日星期一

PCManX on OLPC

感謝jollen前輩的幫忙,讓我有進一步接觸OLPC(傳說中的百元電腦)的機會。

去年年底時就聽了好幾次OLPC的新聞,能真的用到實品,興奮之情真是難以言喻。期待歸期待,真實世界的OLPC用起來感覺倒還不是很順暢。可能是裡頭的軟體版本還沒跟到最新版,或是還不夠成熟,沒有完全發揮硬體完全的效能的原因吧。

想要更新到最新的版本,然而手邊又沒有工具也是沒輒。幸好,拜模擬器之賜,軟體的開發不再死死侷限在硬體上。

OLPC的組織已經有提供好相關的軟體模擬環境和開發工具,讓參與者即使沒有機器也能進行軟體測試與開發的工作。其相關的聯結如下:

幸運的是,OLPC的本質就是Linux系統,只有表面的介面看起來不太一樣,其他的系統設定跟程式環境都一樣。只要拿到OLPC裡的super-user,理論上幾乎可以作到任何在Linux上的事。
「理論上?!」
我們總是需要作一些嘗試來堅定我們的信念。
BBS可說是咱在地特有的文化,適逢(Open-) PCMan於日前釋出2007的最新版本。何不移稙一個BBS軟體到OLPC上呢?經過幾天的嘗試,終於有了初步的成果如下:

2007年6月16日星期六

kboot初探與模擬驗證

kboot本質上是個小型Linux作業系統,但功能卻是個boot loader,何解?kboot本身提供簡單的系統工具,支援檔案與網路操作,可自外界取得kernel image或其他檔案,進而kboot利用了kexec的機制,讓Linux kernel可快速重新啟動,於是具備boot loader的功能。

kexec是一組新的系統呼叫,包含在2.6 kernel中 (視支援架構而定),搭配其user-space的工具kexec-tools,則可在既有的Linux kernel (支援kexec系統呼叫) 中載入其他的kernel (不需要有kexec支援),並給予必要之參數或檔案,如kernel command line與initrd等,這方面的資訊可參考以下文章:

目前,kexec的硬體支援不限定x86,包含ARM與PPC都已有patch現身。那麼,如此的機制到底有什麼價值呢?以往的boot程序是很單純,清一色就是boot loader載入kernel,然後跳到user-mode或者是特定的工作,但現在的系統設計往往不是單一硬體、單一架構就可勝任的,諸如RAID或高負載的備援系統設計,都需要相當繁複的規劃,很顯然就非普通的boot loader可以應付,也很難修改Etherboot去圓滿符合需求,這時候,我們聯想到Linux,搭配到上述的kexec,不就是最美妙的boot loader嗎?在載入新的kernel之前,我們可作任何Linux能做的事情,像是載入firmware並進行設定、掛載NFS、掛載NTFS (透過Linux-NTFS)、... 等等,只要能提供新kernel給kexec-tools工具作載入,最後再透過kexec系統呼叫,就可完成這個「功能強大的boot loader」的終極任務。

kboot就是這樣的概念驗證實做品,使用的情境相當多元。舉例來說,kboot想進行遠端開機 (Diskless),但只有Wireless LAN或3G network可用,這時候就掛載對應的kernel module (包附在kboot中),然後透過user-space的應用程式進行設定,等待連線建立並確保檔案擷取成功,接著就在裝置上執行自遠端取得核心。另一種情境也很有趣,以往Linux distribution都得作通用性與最佳化的妥協,前者往往得將系統劃分諸多核心模組與大量的設定程式,後者往往得針對硬體作多次嘗試,那麼,透過kboot可先啟動generic kernel,然後進行硬體偵測,參考所需的硬體與最佳化組態,重新編譯核心,最後將該核心載入,而這個過程可透過一些設計得當的效能評估工具,一次又一次的重複自動微調,有別於以往的boot loader。關於kboot的應用,可參考以下簡報:後者給予我們極大的想像空間,當我們在新的硬體進行核心與週邊移植時,的確可先把能運作的最低限度核心置入kboot,然後再從不同的開發分支取得新核心並啟動,而這些過程都是透明的,而且不需要燒錄到傳統儲存裝置中,只要資源允許,可在RAM中做到繁瑣的事情。

昨天做了一個小hack,將原本的kboot (Version 11) 進行調整,更動紀錄如下:
Enhancements:
. Provided qemu specific configurations for verifying kboot
. Enable Visibility for gcc-3.4 (symbol hidden)
. Perform size optimizations against user-space packages.
Upgraded:
. kernel - 2.6.21
. binutils - 2.17.50.0.16
. uClibc - 0.9.29
我們甚至不需要單獨的x86機器,就能測試kexec與kboot,只要有能夠運作Qemu的環境即可。首先,取得OrzLab修改的版本:kboot-11-orzlab.tar.bz2,解開後直接打 "make" 就會建構整個系統,包含下載必要的套件、工具,以及編譯與安裝等。搭載於kboot的Linux kernel是精簡的版本,只提供TCP/IP stack、procfs、initrd/initramfs、ne2k NIC driver、VESA VGA framebuffer console等,但足以讓我們作許多應用。

Qemu提供DHCP與TFTP server的模擬,完全省下我們佈署的難度,所以在模擬環境中,所需的操作甚至大幅少於實體。筆者提供了簡單的script名為 "qemu-launcher.sh",直接執行即可,kboot啟動後的畫面如下:
依據Qemu的操作文件,預設透過模擬的DHCP server取得的IP是10.0.2.15,而server自己則是10.0.2.2,上面的畫面展示kboot已經載入一個小型的Linux kernel並出現提示訊息,等待命令操作,我們可打一些指令如下:
看到kernel version 2.6.21與ping連線的狀況,除此之外,還有ssh/sshd可用,所以大可連線到某台server,重新編譯核心程式碼,然後放到某個網路伺服器上。接著我們就要來驗證kexec/kboot的功能。Qemu內建的TFTP server相當好用,直接對應於host上的目錄架構,而就Debian/Ubuntu來說,host的核心會在根目錄建立symbolic link,而vmlinuz與initrd.img就指向目前運作的核心與initrd。

於是,我們在模擬的環境只要下簡單的一行指令即可載入並重新啟動: (鍵入粗體字部份)
kboot: tftp://10.0.2.2/vmlinuz
然後我們會看到 "Start Kernel" 的字樣跳過,然後我們就在Qemu的模擬環境看到啟動目前host上的核心:
因為在之前提供的qemu啟動script中省略root file system的指派,所以會停在kernel panic的畫面,不過這也達到我們的目的,驗證kexec/kboot,有了這個便利的模擬測試環境,未來也可作不同的變化。

2007年6月14日星期四

WebKit的Gtk+支援

khtml是在KDE 2中,集合檔案檢視系統與網頁瀏覽器於一身的Konqueror內部主幹,是極為精美細膩的設計,如果說為一窺 KDE 技術最佳的進入點,那真是一點都不為過。由於khtml卓越的設計,很快就出現以khtml為基礎的網路瀏覽器專案,比方說運作於Qtopia (Core)之下的Konqueror/Embedded,而Apple Inc.也採納khtml,部分重新設計與最佳化就變成WebCore (MacOS X內建瀏覽器Safari的核心基礎建設)。而業界的應用也很廣泛,像是韓國嵌入式系統廠商Mizi Research就曾將Konqueror/Embedded經過一番調整,成為相當強悍的瀏覽器。

Apple Inc.提供了大量的修改,讓khtml的品質獲得極大的提昇,又在KDE開發者的斡旋下,Apple Inc.終於採納了社群開放發展的模式,於是KDE與Apple Inc.兩組開發人馬傾向共享WebKit的程式碼基礎 (codebase)。接著,Nokia也宣佈WebKit為基礎的S60WebKit (針對S60手機平台)與gtk+-webcore (針對Gtk+/X11環境),並依循LGPL與BSD License的方式,將修改貢獻回WebKit專案。

WebKit在這三年內蓬勃發展,提供了許多不同軟硬體平台的移植,值得一提的是新出現的GDK (Gtk+的低階圖形處理部份) 移植,這意味著WebKit可運作於GDK支援的環境,就嵌入式系統來說,我們會關注linux-fb與DirectFB兩個Gtk+/GDK所支援的backend。在近半年來的發展,WebKit的Gtk+/GDK移植已到堪用的地步,針對Nokia770/MaemoOpenMoko的硬體移植也出現成功案例。

為了降低建構WebKit/Gtk+的難度,我做了簡單的建構系統 (檔案:webkit-build-script.tar.bz2),允許從Subversion取出最新的發展版本,並作必要的設定,最後進行編譯。下載並解開後,直接執行以下script:

# ./BUILD.sh
中間會透過apt-get取得必要的開發套件。建構完畢後,大致的執行畫面如下:
(1) wiki.openmoko.org
(2) Google MapsWebKitOpenMoko GTA01也開始運作了,但還是有很多需要調整之處,這也是今年Google Summer of Code的項目之一,期待這方面的新進展。

2007年6月11日星期一

從Chrasis談手寫辨識引擎在移動裝置的機會

Gentoo TaiwanPalatis日前公開他發展中的手寫辨識引擎與訓練程式,可參考blog文章「Chrasis 0.1.0 alpha!」,專案發展紀錄可參考Chrasis - Chinese Handwriting Recognition As-Is」,正如版本號所宣示的,現在還有很大的改進空間,不過已經初步可運作,以下是其訓練手寫辨識程式的執行畫面:
程式碼可透過Subversion存取:

# svn co svn://svn.berlios.de/chrasis/Engine/libchrasis/trunk libchrasis
# svn co svn://svn.berlios.de/chrasis/Linux/ChrasisTrainer/trunk ChrasisTrainer
libchrasis為手寫辨識引擎,其相依性有: (以Ubuntu 7.04為例)
  • libxml++2.6-dev
  • libsqlite3-dev
  • sqlite3
  • libboost-dev
ChrasisTrainer顧名思義就是訓練程式,以Gtk+打造,其相依性如下:
  • libgtkmm-2.4-dev
  • llibxml++-2.6-dev
測試了幾個簡單的中文字,都能正確辨識,算是不錯了。當然,手寫辨識的議題很複雜,以下是筆者在wiki - ChineseInformationProcessing的「手寫輸入」段落紀錄的部份資訊l:

以下為 rabit 的個人見解 (Modified by User:jserv):

  • KanjiPad 本身使用的辨識方法是很簡單的字典法,當使用者透過手寫版或滑鼠寫出字時,程式辨識出筆劃種類,並紀錄每個筆劃的順序,然後根據字典查出候選字。也因此,KanjiPad 根本不考慮寫出來的字形貌是否相似,只求筆劃順序相符。

chinput_5.gif

  • 以 Cinput (修改自 Kanji Pad) 的圖為例,「林」這個字辨識出來的候選字有「林、杯、枝、板、茂」,這幾個字右半邊的「木、不、支、反」筆劃順序都是跟「木」是相似的。這樣的演算法辨識 率是不高的,一但筆順不對,就很難辨識出來,不過話說回來,也不能太苛求 KanjiPad,因為它原本的用途就是日本人寫來學習漢字用的,可以說本來就是當作字典使用。
  • 中文手寫辨識是難度相當高的, 困難的地方有二:
    • 就技術而言,在辨識方面會用到許多數學模型,如 Baysian Decision Theory hidden Markov models、類神經網路等,而辨識中文還必須對中文字作分析,找出每個中文字的特徵 (筆形、筆順等),若要更精準,需拆解中文字成基本的部件,來作分析 (有點像漢字跡因工程),這時就要處理寫字上連筆的問題,技術上有實現的複雜度,但或許還不是最困難的。
    • 必須對每一個字的分析,建立資料庫,這是需要大量的成本 (包含時間、人力等),中文字尤其複雜,除了大量的漢字,還有異體字、罕用字等,我想這對 open source 是最困難之處,這跟 open source license 中文字型的狀況有些類似。
看似這是NP-Hard的問題,但如果我們思考Mobile 2.0對我們的衝擊,可以發現,大多數的手持裝置都需要手寫、筆跡、觸碰軌跡辨識的技術,而且也依賴原本在桌面系統的軟體元件與操作習慣,此時,危機反而就是轉機。具體來說,我們可思考「新酷音」一類智慧型輸入法如何移植到手持式裝置如PDA或SmartPhone一類的裝置,基本上,運算速度與儲存裝置都不是大問題 (早在兩年前,「新酷音」輸入法系統就證明在某隻SmartPhone上正確運作),真正的難題反而是輸入法的「輸入」本身。是的,以「新酷音」來說,支援兩種基本符號:
  • 注音符號
  • 拼音字母
這兩者背後也有學問,光是注音符號對照的鍵盤排列就可玩許多花樣,諸如許氏注音、倚天26鍵等等,拼音系統就不必多說,在台灣根本就是多頭馬車。以往,「新酷音」的開發者花了很大的心力去維護這些子系統的可用性與正確度,整合到libchewing (核心函式) 中,但如今要整合到手持式裝置,就面臨新問題:
「如何將傳統鍵盤的行為導入輸入法系統?」
我們首先會想到手寫辨識,就目前的系統來說,多半會內建OSK (On-Screen Keyboard),所以「新酷音」理所當然可架構於OSK之上,不過這與我們中文打字者的思維有很大的落差。何以此說?試想,「新酷音」的中文簡介是什麼?就是「智慧型注音輸入法」,透過統計與預測方式,大幅降低同音字詞的出現率,進而改善注音輸入的速度,使用鍵盤只是一種過度,真正使用者腦海中的思維,仍是「注音」(或拼音)本身,所以,日前筆者也跟Palatis聊到一種新途徑:
「何不直接辨識注音符號,然後導入新酷音輸入法引擎去作猜字處理?」
這種技術難度對於Chrasis一類的簡化手寫辨識引擎來說,算是綽綽有餘,如果不討論太複雜的連寫與草寫議題的話。某種角度來說,這說明了Mobile 2.0的思維方式:「過去的桌面技術有機會走入移動裝置之中」與「打破過去封閉技術的藩籬,個人也得以貢獻新的技術元素到移動裝置設計」,如今,我們有完全開放程式碼並開放手機規格與實做的openmoko、有高效率的動態組字技術,以及最寶貴的資源,也就是富有高度創意的自由軟體開發者,其整體的影響將會很有趣,手持裝置才正要作更有意義的應用,咱們拭目以待。

Xorz/Embedded的動態組字實做

之前的文章「Xorz/Embedded作為Phone UI」與「組字技術與手持式裝置的新機會」提到輕量級視窗圖形系統的實做進度,同時也思考組字技術帶來的新契機,無論是技術與實務規劃面來說,都還有很大的商議空間,但筆者認為這是必要的基礎建設。利用週末,終於在Xorz/Embedded實做出基本的中文動態組字功能,執行畫面如下:

以上展示「黃」(Unicode 0x9EC3)與其搭配不同組件 (部首) 的呈現方式。原本single.fnt (剎那單線體) 定義為:

!009EC300|黃0=0000162E0001F02E00005A1100015A5E0000A8110001A85F0000595F0001AC5F00000A5F0001F55F00003C7300013CCE00003D7B0001CA7B0001CACF00003B9E0001C99E00008066000180C1000062D6000242EB000116FA00009AD00002D0E50001DEF700003CC00001CAC0
又,考慮美觀,我從文鼎楷體轉出了stroked font,從而做了細部的調整,這方面還得與剎那搜尋工坊討論如何整合,但基本上組字的概念是可以延續的。「黈」這字在single.fnt是如此定義:
009EC800|黈0=黃0131272E1主0811078D9
相當明顯就是「黃」與「主」兩部件的左右結合,同理,「黌」則定義如下:
009ECC00|黌0=00D07E66B黃0156AD78A
改為上下部件的結合。當然,目前的實做還很陽春,但已經看得出效益,以目前的stroked font engine來說,只要先描述以上三個組件,如「黃」與「主」:
/* 0x9ec3 (黃) */
3, 66, 56, 0,
'm', 28, -36,
'2', 29, -36, 29, -36,
'2', 33, -37, 39, -37,
...
接著就採用single.fnt所定義的組字表示,去作遞迴表示即可,大幅省下儲存空間,也可避免許多維護成本,更重要的是,這一舉克服以往字型檔與程式碼不對稱的問題。除了中文動態組字外,其實Xorz/Embedded的繪字引擎也允許一些變化,比方說「Q版」的呈現,有點像是塗鴉文字,行文甚至有互相疊合的效果,這是為了配合某些特殊的應用,如廣告文字,所特別設計的系統,畢竟Xorz/Embedded一開始的定位就是針對嵌入式系統的特製輕量級圖形系統。

恰好TOSSUG在本週二也請到國內在動態組字學有專精的前輩,為我們分享中文缺字議題、動態組字技術,以及進行中的變革,詳情可參考「Tossug 2007 年第 7 場心得分享」,如果當天有空檔,或許筆者也可來作些介紹與展示。

2007年6月1日星期五

build u-boot from sources

因為openmoko patch的u-boot有支援Samsung S3C24xx的stepping stone,所以build看看。

主要是follow這一篇文章 "Migration to bad block tolerant builds",說明比u-boot那一篇仔細 (但是我apply 609的patch沒有成功,所以還是使用main stream)。

工作的目錄是 /home/openmoko

裝好subvesion,設定svn使用proxy,在~./subversion/server中加入proxy server,port :

http-proxy-host = 10.1.1.200
http-proxy-port = 3000
checkout openmoko 到 openmoko 目錄
$ svn co https://svn.openmoko.org/ openmoko
安裝git-core,改變default git tool (debian etch)
$ aptitude install git-core
$ update-alternatives --config git
== 選 "git-scm"
export 好http_proxy,checkout u-boot
$ git clone http://www.denx.de/git/u-boot.git
(需要等待一段時間)

取得cross toolchain : 因為monotone出不去proxy (雖然mailing list中聲稱新版的monotone可以經過proxy,可是我這裡還是出不去),所以只好直接從 openmoko拿build 好的cross tool
$ wget -r -L http://buildhost.openmoko.org/tmp/cross
(需等待更長時間,且lib/下的檔案有些沒有抓回來,要確認一下,加上 "-c"抓沒抓到的folder。修改 bin 下的file,設為可執行。)

把抓下來的toolchain copy到 ..
/space/fic/openmoko/gta01/tmp/cross
設好PATH:
$ export PATH=/space/fic/openmoko/gta01/tmp/cross/bin:$PATH
u-boot - apply patch: (要先裝好quilt)
$ cd u-boot
$ export QUILT_PATCHES=/home/openmoko/openmoko/trunk/src/target/u-boot/patches
$ quilt push -a
Ok,沒有error message。

build u-boot - config and make:
$ make ARCH=arm gta01bv2_config
$ make ARCH=arm
完成。