Jserv's blog

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，致使效能大打折扣

是此，MicroXwin 提出新的途徑，在不更動既有 X client / Toolkit 的前提下，將 X serever 的工作搬移到底層作業系統，成為一個新的服務，並且，捨棄 X protocol 與網路通透性的機制，成為修正性、典型的繪圖系統，以下是示意圖：

由上圖，我們可見到若干元件：

• 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 與 libXext 等 userspace library 依據 BSD style license 發佈，也提供針對 x86, ARM, MIPS 等硬體架構的 kernel module，就官方的說法，MicroXwin 在空間與記憶體需求量，均大幅低於 Xorg server，以 x86 架構為例，個別軟體元件的空間需求如下：

• libX11.so : 720K bytes
• libXext.so : 7K bytes
• Kernel module x11.ko : 200K bytes

相較而下，Xorg X server 佔用了 1.8M bytes 的空間。而針對 ARM 9 硬體，以 Nokia 770 Linux Tablet 為主要效能評比的對象，OpenHanded (已被 Intel 收購) 與 Nokia 的工程團隊已做了若干效能改進，提出 Xomap，這個奠基於 KDrive / TinyX 架構、針對 TI OMAP 硬體加速的 X server，MicroXwin 與其相較，絲毫不遜色，而且有亮眼的效能突破。網頁 [Demo] 透過 x11perf 羅列了效能評比數據，筆者做了圖表整理如下：

由此可見，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 更高的處理優先權

自由軟體法律授權工作坊

本月 (11 月) 的 26 日，中央研究院資訊科技創新研究中心自由軟體鑄造場 (OSSF) 將舉辦 [自由軟體法律授權工作坊] 的研討會，藉此活動共同探討企業在使用開放源碼時所遇到的授權與法律議題，以下摘錄活動訊息：

• 對象：嵌入式廠商及對自由軟體法律議題有興趣者
• 人數：約 80 人
• 費用：全程免費，中午供餐
• 議程：
  • 09:40~10:30 主題一：軟體的授權觀念與自由軟體授權類別
  • 10:40~11:30 主題二：自由軟體的法律爭訟及商業應用模式
  • 11:40~12:00 主題三：Focus Group Discussion

小弟也會出席此研討會，歡迎指教，謝謝！

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 都非常歡迎 :-)