November 14, 2008
MicroXwin : 針對嵌入式系統的高效能 X Window System 實作

新創公司 DSPSOFT INC 日前提出針對嵌入式系統的高效能 X Window System 實作,即 [MicroXwin],由該公司創辦人兼 CEO,Vasant Kanchan,領導嶄新途徑的開發與產品化。MicroXwin 的思維乃是著眼於拜自由軟體蓬勃發展所賜,豐富的 X 應用程式有如過江之鯽,但,在有限硬體能力的嵌入式環境中,是否有機會獲得良好的呈現與使用者互動能力呢?為此,MicroXwin 用獨特的方式改良 X 的設計。
X Window System 本質上是圍繞於網路通訊的視窗系統,X server 透過硬體,負責將 X client 要求的繪圖動作,予以呈現並處理運作所需的 I/O,而 X protocol 就是如此設計的核心。X 應用程式就是 X client,為了開發豐富的應用程式,會有 Gtk+ 與 Qt 一類的 Toolkit / widget set,下圖是運作示意圖:

在沒有特殊硬體加速機制 (如 DRI 與 GLX/OpenGL) 的前提,以下因素導致原本 X Window System 效能低落並佔用系統資源:
- 基於 X protocol 的規範,X client 與 X server 各自保有 buffer 與格式化的繪圖指令操作
- X client 與 X server 間的必要的同步化通訊與 round-trip
- 對於 ARM 9 一類廣泛使用的嵌入式處理器架構,系統設計有 MMU/cache 本該能提昇的處理效能與彈性,但頻繁地在 X 應用程式與 X server 間作 context switch,導致 cache flush,致使效能大打折扣

由上圖,我們可見到若干元件:
- X11.ko kernel module : 實做部份 X server 的功能,並開放 /dev/x11dev 的介面給 X client library 存取
- libX11.so 保持與原本 Xlib 二進位相容的 API
- libXext.so 等 X extension library 則實做 X extension 所需的呼叫,但針對 /dev/x11devb 介面,而非網路通訊的 X protocol
- X core font 由 X11.ko kernel 處理,免除繁複的記憶體操作
- 針對向量字體,則由 X client 端,透過 Xft/Fontconfig 處理,但更直接的呈現
- Low latency 與 Low round trip
- 大幅減少 X request / response 所需的 buffering,免去昂貴的通訊成本
- 消去 context switch 的負擔,並避免 ARM 9 一類嵌入式硬體的 cache flush 問題
- 透過 X11.ko kernel module,圖形資料是直接由 userspace 複製到 framebuffer 硬體
- (幾乎) 不需更動到任何既有 X 應用程式
- libX11.so : 720K bytes
- libXext.so : 7K bytes
- Kernel module x11.ko : 200K bytes

由此可見,MicroXwin 相較於 Xorg X server,在 asynchronous display 有著 62% 的效能提昇,而在 synchronous display of images 則有 384% 的提昇,這是主要架構變異使然,官方也提供若干組態與執行檔供驗證評估。整體來說,MicroXwin 的設計特點:
- 快速的 round-trip 與 synchronus request 時間
- 讓 UI Toolkit 得以有更快更順暢的表現
- Kernel module x11.ko 有著較 Xorg server 更高的處理優先權
Posted by jserv at 01:20 PM
| Comments (9)
November 12, 2008
自由軟體法律授權工作坊

本月 (11 月) 的 26 日,中央研究院資訊科技創新研究中心自由軟體鑄造場 (OSSF) 將舉辦 [自由軟體法律授權工作坊] 的研討會,藉此活動共同探討企業在使用開放源碼時所遇到的授權與法律議題,以下摘錄活動訊息:
- 對象:嵌入式廠商及對自由軟體法律議題有興趣者
- 人數:約 80 人
- 費用:全程免費,中午供餐
- 議程:
- 09:40~10:30 主題一:軟體的授權觀念與自由軟體授權類別
- 10:40~11:30 主題二:自由軟體的法律爭訟及商業應用模式
- 11:40~12:00 主題三:Focus Group Discussion
Posted by jserv at 08:18 PM
| Comments (0)
fbvncserver : 將 Linux framebuffer 作為輸出的 VNC server
日前在調整 LCD panel / controller 的 Linux device driver 時,因疑似 panel 硬體處理不善,導致無法釐清問題是發生於軟體層面,抑或潛在的硬體議題,於是需要觀察 /dev/fb* 的內容,將腦筋動到 VNC 上面,最後做了一個小工具 fbvncserver,將 Linux framebuffer 作為輸出的 VNC server。參與 OpenEZX 專案時,Harald Welte 寫了一個小工具 [fbgrab-viewer],原理是透過在標的裝置 (target) 端執行 [fbgrab],不斷將從 Linux frambuffer 擷取的影像,經由轉換,傳輸到桌面 (host) 端的 viewer,即可監控裝置端的畫面,當然,實際上得考慮傳輸的間隔,所以大概是每五秒傳輸一張。這個小工具在我們早期進行 Openmoko 硬體驗證時,仍派上用場,不過,問題是間歇性的擷取與轉換影像為 PNG 圖檔,還是太沈重。而過去 Sharp Zaurus Linux PDA 上,有個 [fbVNCServer] 工具,則巧妙地建立一個 VNC server,將 Linux framebuffer 作為輸出,允許桌面端瀏覽與操控 PDA 的畫面,看似很理想,但這個軟體太依賴 Zaurus PDA 的硬體組態,本身也有點複雜,也沒有維護,所以乾脆弄個新專案。
同樣透過 [LibVNCServer] 來建構 VNC server,大幅減輕工作量,雛型實做可參考 [fbvncserver.c],授權方式為 GNU GPL,參考的執行畫面如下:

上圖主要的畫面是 TightVNC client,視窗標題列的 AG101 則為我的裝置端名稱,當 VNC server 啟動時,終端機會有以下輸出:
/tmp # ./fbvncserver
Initializing framebuffer device /dev/fb0...
xres=800, yres=480, xresv=800, yresv=480, xoffs=0, yoffs=0, bpp=16
Initializing Framebuffer VNC server:
width: 800
height: 480
bpp: 16
port: 5900
Initializing server...
07/11/2008 14:00:24 Listening for VNC connections on TCP port 5900
這裡裝置端的 IP 為 10.0.4.80,而桌面端為 10.0.4.78,現在後者的 VNC client 試圖連線到前者的 fbVNCserver,會看到以下的終端機訊息更新:07/11/2008 14:00:31 Got connection from client 10.0.4.78 07/11/2008 14:00:31 other clients: 07/11/2008 14:00:31 Client Protocol Version 3.8 07/11/2008 14:00:31 Protocol version sent 3.8, using 3.8 Dirty page: 70x80+6+0... 07/11/2008 14:00:31 rfbProcessClientSecurityType: executing handler for type 1 07/11/2008 14:00:31 rfbProcessClientSecurityType: returning securityResult for client rf8 07/11/2008 14:00:31 Pixel format for client 10.0.4.78: 07/11/2008 14:00:31 32 bpp, depth 24, little endian 07/11/2008 14:00:31 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 07/11/2008 14:00:32 Using compression level 1 for client 10.0.4.78 07/11/2008 14:00:32 Using image quality level 6 for client 10.0.4.78 07/11/2008 14:00:32 Enabling X-style cursor updates for client 10.0.4.78 07/11/2008 14:00:32 Enabling full-color cursor updates for client 10.0.4.78 07/11/2008 14:00:32 Enabling cursor position updates for client 10.0.4.78 07/11/2008 14:00:32 Enabling LastRect protocol extension for client 10.0.4.78 ... (略) ...這些訊息是由 [LibVNCServer] 所輸出,表示 VNC/RFB session 已正確建立與運作。目前的實做假設裝置端的 bpp 為 16-bit (RGB565),在多數的硬體裝置應算堪用,當然,任何修改與 patch 都非常歡迎 :-)
Posted by jserv at 11:37 AM
| Comments (0)