Showing posts with label 一千零一夜. Show all posts
Showing posts with label 一千零一夜. Show all posts

Thursday, June 25, 2009

一千零一夜之 GEM Object

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。


GEM object 是一種 buffer,一種可以在 A 程式被配置,在 B 程式被使用的 buffer。當 userspace 產生一個 GEM object 時,以 i915 為例,它會呼叫 drm_gem_object_alloc。從這個函數的頭幾行

struct drm_gem_object *obj;

BUG_ON((size & (PAGE_SIZE - 1)) != 0);

obj = kcalloc(1, sizeof(*obj), GFP_KERNEL);

obj->dev = dev;
obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
if (IS_ERR(obj->filp)) {
kfree(obj);
return NULL;
}


可以看出,它只是一塊 shared memory。就這個方式來看,GEM object 其實不是新的東西。

但這塊 buffer 除了 A、B 程式會用到外,它還另外有一個使用者,這個使用者是 GPU。之所以把 shared memory 包裝成 GEM object 最主要的原因是,kernel 需要同步 CPU 和 GPU 對這塊 buffer 的存取。很明顯地,如果讓 CPU 與 GPU 同時寫入同一塊記憶體,出來的結果一定無法預期。在 GEM object 裡,處理同步的方法是引入 domain 的機制。所有人在存取 GEM object 前,必須先把它的 domain 設好。如果是 GPU 要讀取或寫入,那就需要先把 read domain 或 write domain 設成 GPU;相對的,如果是 CPU 要讀取或寫入,則需要把 read/write domain 設成 CPU。DRM 保證的是,只要正確地指定 domain,存取到的資料也會是正確的。

為了解 domain 跟同步的關係,我們可以看一下當我們把 read domain 指定為 CPU 時,kernel 會幫我們做什麼處理。這部份完整的程式碼可以在 i915_gem_object_set_to_cpu_domain 看到。

首先,kernel 要確定之前所下的 GPU 指令已經全部執行完畢,而且 GPU cache 要 flush 掉

i915_gem_object_flush_gpu_write_domain(obj);
ret = i915_gem_object_wait_rendering(obj);


GPU 的運作方式是會依序執行某個指定的 ring buffer 裡面的指令,而開發者要做的是把指令放到這個 buffer。為了達到目的,kernel 會在 ring buffer 最後加上 flush 跟 interrupt 指令,並且開始等待中斷。我們可以想像,當 kernel 收到中斷時,也就表示之前的指令都已經執行,包含它自己加上的 flush 指令。

事實上,CPU 除了直接存取 shared memory 外,也可以從 AGP aperture 去存取,這在 i915 裡稱做 GTT domain。所以 kernel 也要確定這邊沒有資料被 cache 住

i915_gem_object_flush_gtt_write_domain(obj);


這些動作可能造成記憶體上的資料被改變,而,這時候 CPU 還不知道這件事。所以只要再確保 CPU 可以知道這些變動

i915_gem_object_set_to_full_cpu_read_domain(obj);
if ((obj->read_domains & I915_GEM_DOMAIN_CPU) == 0) {
i915_gem_clflush_object(obj);
obj->read_domains |= I915_GEM_DOMAIN_CPU;
}


我們就可以說 GEM object 已經被移到 CPU read domain。

GEM object 是 shared memory 的特性,讓 X server 可以直接把 buffer 傳給 client 做 DRI。它同時也可以當做到 OpenGL 裡頭各種 buffer object 的 storage。除了 Intel 外,在 2.6.31 也可以看到初步的 ATI Radeon KMS 支援。雖然從使用者的經驗來看,似乎只是進入另一個黑暗時期。但是在領袖的帶領下,我們好像也可以看到光了!

Wednesday, June 24, 2009

一千零一夜之 Kernel and Firmware

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

Driver 需要 firmware 時會呼叫 request_firmware,這個函數會在 /sys 底下產生適當的裝置讓 userspace 上傳 firmware 給 driver。它會等到 firmware 上傳完成 (或發生錯誤) 才回傳。除了建立適當的裝置,它也會送一個 uevent,內容類似

KERNEL[1245809267.000297] add      /devices/pci0000:00/0000:00:1c.2/0000:02:00.0/firmware/0000:02:00.0 (firmware)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/firmware/0000:02:00.0
SUBSYSTEM=firmware
FIRMWARE=iwlwifi-3945-2.ucode
SEQNUM=1226


uevent 事件通常是 udev 在處理,在遇到 firmware 事件,也就是 SUBSYSTEM 是 firmware 的事件時,udev 預設會執行 /lib/udev/firmware.agent (在 Debian 上) 來上傳 firmware。簡化過的 firmware.agent 其實只做了

echo 1 > /sys/$DEVPATH/loading # 準備上傳
cat $firmwaredir/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading # 上傳完畢


注意到上面大寫的變數內容都是 uevent 提供,像是 $DEVPATH 就是 kernel 剛產生用來接受 firmware 上傳的虛擬裝置。

這是 firmware 擺在 filesystem 上的情形。當 CONFIG_FIRMWARE_IN_KERNEL 打開時,如果 driver 被編進 kernel,firmware 也會一起被編進去。在 request_firmware 中有一段

for (builtin = __start_builtin_fw; builtin != __end_builtin_fw;
builtin++) {
if (strcmp(name, builtin->name))
continue;
dev_info(device, "firmware: using built-in firmware %s\n",
name);
firmware->size = builtin->size;
firmware->data = builtin->data;
return 0;
}


會先檢查 driver 要求的 firmware 是否有內建。這邊的 __start_builtin_fw 與 __end_builtin_fw 是 link time 產生的 symbol,所以不會在任何 C code 找到它們的定義。在 vmlinux.lds (或 include/asm-generic/vmlinux.lds.h) 可以看到,它們的值會是所有 .builtin_fw section 內容的開始位址與結束位址。

.builtin_fw 的內容要再找到 firmware/Makefile。在那份 Makefile 可以看到 kbuild 會為每一個要內建的 firmware 產生一份 assembly code。這些 assembly code 編出來的 object code 會跟 kernel link 在一起,達成 firmware 內建的目的。從 assembly code 可以看出,這些 object code 的內容會是 firmware 本身,以及一個放在 .builtin_fw section 的資料結構,給出 firmware 的檔名、位置、還有大小。

這邊看到內建 firmware 的做法其實是 kernel 常見的手法之一。寫 driver 最開始會加的 module_init(entry_point) 是另一個例子。這些 macro 會產生 initcall,而所有的 initcall 在 link time 也是用類似的方式被收集。在電腦剛開機進 userspace 前它們會依照被收集的順序依序被執行。這邊可以看到一個要注意的小地方。在每個 subsystem (rtc, scsi, ...) 的 Makefile 中,核心的部份必須放在 driver 之前。

Wednesday, April 29, 2009

一千零一夜之 eagle

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

之前的文章提到過,只要有適當的 loader,DRI driver 也可以用在 X server 以外的平台,eagle 就是一個例子。eagle 提供開發者接近於 EGL 的 API,並且可以運作在支援 DRI2 的 X server 與支援 GEM 的 intel drm 之上。這篇文章主要想討論後者。

eagle 與視窗系統無關的實作,行數落在大約 800 行左右。intel drm 的支援也只在 250 行左右。對它使用到的技術有些許了解後,只要花一個晚上就可以讀完,算是學習 linux 3D 實作不錯的途徑。也因為它的簡單,閱讀過程如果有難以理解的部份,也可以馬上修改跑跑看。如果這兩部份看完後想要再看 DRI2 的部份,eagle 也可以讓人滿足。

intel drm 的支援在 eagle 中稱為 backend,以 EagleBackend 表示。Backend 與視窗系統相關,要提供的主要功能有

  • 建立 EGLSurface

  • 提供 DRI driver 需要的 GEM buffer

  • 更新畫好的內容到螢幕上



intel drm backend 建立 EGLSurface 的函數是 intelCreateSurfaceForName。這邊的 name 型別為 uint32_t,指的是 GEM buffer 的 identifier。如果沒給的話,backend 會產生一塊新的 buffer。client 可以要求 double buffering,這時 surface 的 backBuffer 會設為 EGL_TRUE。

intelGetBuffers 負責提供 DRI driver 需要的 GEM buffer,像是 front buffer,back buffer 或 depth buffer 等。這邊要特別注意,在 double buffering 的情形,也就是 backBuffer 設為 EGL_TRUE 的時候,即便 DRI driver 要求了 front buffer,intelGetBuffers 還是會產生新的 buffer 回傳給 DRI driver,而不是回傳 intelCreateSurfaceForName 時給定或產生的 front buffer。這個新產生的 buffer 也被稱為 fake front buffer。

最後看到 intelSwapBuffers,也就是 eglSwapBuffers 會呼叫的函數。可以看到,當不是 double buffering 時,這個函數會直接 return,因為 DRI driver 本來就是畫在真正的 front buffer 上。若是 double buffering 的話,intelSwapBuffers 會把 DRI driver 以為的 (fake) front buffer 複製到真正的 front buffer 上。

Backend 大致上就處理這些事情。eagle 的核心則負責提供接近 EGL 的 API。它同時也是 DRI loader,選定適當的 EagleBackend 並載入適當的 DRI driver。除了選擇與 dlopen 適當的 .so 檔外,核心其餘的程式碼大多在處理 EGL 的型別與 DRI 型別的對映。這個部份很基礎,也是所有想寫 loader 的開發者都要熟悉的東西。這邊的程式碼比較直接,有興趣的人可以自行閱讀。

在初次研讀 eagle 的過程中,我最感興趣的其實是這篇文章沒提到的 glapi。這是 mesa 或 mesa 自動產生的程式碼,其中後者佔了絕大多數。在許多功用中,其中一項功用是提供 OpenGL (ES) 的 global symbols,讓 link 到 libeagle.so 的程式可以呼叫 gl* 等函數。這可以算是 mesa build system 的一部份,對熟悉 linux 3D 的組成有相當的幫助。

Friday, April 17, 2009

一千零一夜之 Android Binder

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

Binder 是 android 大量使用的 IPC 機制。當使用者在 launcher (home) 按了某個 App 時,這個動作會經由 ActivityManager 向 zygote 發出請求,並從 zygote fork 出新的 process 執行被選擇的 App。這個過程大致上有 4 個 process 參與:home、system server、zygote 和新產生的 appA。更仔細去看的話,

  1. system server 向 home 送出 touchscreen 事件

  2. home 向 system server 送出 start activity 事件

  3. system server 向 zygote 送出 appA 的啟動參數

  4. appA 向 system server 送出 attach 事件


除了第 3 項以外,其它跨 process 的溝通都是採用 binder。Zygote 是 android 上少數幾個聽 unix socket 的程式。驗證這個說法最簡單的方法是去看 process 的 memory maps 還有 opened fd,這個技巧在之前有用過,這邊暫且略過。

一個 IPC 機制的效能很大一部份取決於它資料交換的能力,從這點去切入是不錯的途徑。所有參與 binder 的 process 都會在一開始向 /dev/binder 裝置 mmap 一塊 read-only 的記憶體,大小在幾個 MB 左右。A process 傳送資料給 B process 的做法是,由 A 對 /dev/binder 做 ioctl 將資料先送給 binder driver。依資料大小,binder driver 動態配置足夠的 physical memory 存放來自 A 的資料,並在 B 一開始 mmap 得到的 address space 裡尋找一段足夠大且未使用的 address area。找到後,binder driver 會修改 B 的 page table,讓這段 address area 映射到剛剛動態配置的 physical memory。如此一來,B 可以直接存取 A 送過來的資料;等到 B 不需要這些資料時,再由 B 負責把這塊記憶體還回去給系統。這段實作可以參改 binder driver 的 binder_update_page_range 函數。

Process 對 binder 的操作只透過 ioctl 做 buffer 的讀寫。Buffer 的內容是一系列的 (command, argument) 組。每個 command 為 4 bytes,argument 的長度視 command 而定,可能是固定的,也可能是變動的。當 A 跟 B 交換資料時,通常會由一方送出 BC_TRANSACTION command,再由另一方回覆 BC_REPLY command。Transaction/reply 的 argument 除了一段 header 外,其餘的資料部份會使用上一段討論的方式做交換。資料的長度跟內容由 A、B 另行約定,可能是整數、浮點數或字串等。除了上述的基本資料型別外,還有三種用 struct flat_binder_object 表示的特殊型別:BINDER、HANDLE、FD。FD 型別讓 A、B 可以交換 file descriptor,也就是說,A 可以打開某個檔案,把 fd 傳給 B,讓 B 去讀寫。或者說,也是更重要的,surface manager 可以準備一塊 surface,把 surface 的 fd (一塊 ashmem 記憶體) 傳給一個 app,讓 app 可以在上面作畫。有了這層理解,我們對 android 可以有更自由的發揮,例如,可以不改一行 cairo 的程式碼,就利用 cairo 與 c++ 寫出一個會動的時鐘:



回到正題,我們知道 binder 還有 BINDER 與 HANDLE 這兩個特殊型別。它們的功用可以用 service port 跟 connection 做類比。就像 httpd 可以開 80 port 提供服務,client 可以跟它建立 connection 使用服務一樣,在 android 上頭,WindowManagerService 可能建立了一個 BINDER,提供了視窗操作的服務。其它程式可能會建立這個服務的 HANDLE。在 binder 之上,android 提供了 aidl 讓開發者可以把 remote service 當做 local object 操作,所以開發者可以直接呼叫 mWindowManager.setRotation 來旋轉螢幕,而幾乎可以不用知道 BINDER 跟 HANDLE 的存在。

當一個 process 收到 transaction 的時候,如果 binder driver 發現 process 沒有任何 thread 已經準備好等著要處理,等到下次有 thread 來處理時,它會收到 BR_SPAWN_LOOPER 的訊息,userspace 也會多產生一個 thread 專門對 /dev/binder 做 I/O,確保下次有 transaction 的時候,有比較高的機會是已經有 thread 準備好了。提個數字,在 android sdk 1.5 preview 的 emulator 剛開好機時,在我的機器上,Phone App 會有 11 個 thread,而其中有 6 個 thread 是跑在同一個迴圈裡等著對 /dev/binder 做 I/O。這項機制相信是為了縮短應用程式的反應時間。

Binder 再探討下去還有許多東西可以討論,例如 android native library 沒有 aidl 可以用,它如何建立操作 binder 的物件?或者 native code 裡面常常看到的 sp<>、wp<> 跟 binder 的 reference counting 關係為何?對 binder 的功能有初步認識後,再去理解這些實作會顯得直覺許多。

Monday, April 6, 2009

一千零一夜之 DRI2 Overview

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

Linux 的圖形加速一直是個問題,不過這個問題在最近幾版的 kernel 隱約可以看到一些希望。從 2.6.28 的 GEM memory manager 到 2.6.29 的 kernel modesetting,由 Intel 與 RedHat 的開發者所提出的加速架構已經進入 kernel,雖然目前採用這些架構的只有 Intel 自身的驅動程式,但其它繪圖晶片的 open source 驅動程式勢必也得跟隨此架構。在 Intel 與 AMD 相繼釋出 datasheet 後,或許有天所有的使用者都可以享用這些成果,不再依賴私有的驅動程式。

去年年中 GEM 公佈後,許多架構迅速翻新,DRI2 最後也環繞著 GEM 在設計。DRI (Direct Rendering Infrastructure) 是各家 open source 驅動程式所依循的架構,雖然處處都可以看見這個名詞,但是要了解它背後的實作卻不太容易。困難的地方在於 DRI 的組成份子很多,而且大部份來頭都不小。以 Intel 的 945GM 為例,在 kernel 有 drm.ko 與 i915.ko 兩個模組,對映到 userspace,有 drm 提供的libdrm.so 與 libdrm_intel.so;在 xserver 有 libglx.so 與 libdri2.so 這兩個 extension,以及 xf86-video-intel 提供的 intel_drv.so;最後在 mesa 也有 libGL.so 以及 i915_dri.so。習慣上,intel_drv.so 被稱作 2D driver 或 DDX driver,i915_dri.so 則是 3D driver 或 DRI driver。從一個 3D 程式被執行時到顯示在螢幕上,參與這個看似普通的過程背後就是上面這些檔案。

DRI 最重要的內涵在於,一個 X client 可以向 X server 取得視窗的 buffer(s),並利用硬體加速在上面直接繪圖,不再透過 X server。Kernel 在 DRI 扮演的主要角色是讓多個 process 可以共享 (GEM) buffer,還有接受與執行 process 傳來的硬體指令。這邊困難的地方之一在於 CPU 跟 GPU 都有各自的 MMU 與 cache,所以有許多同步的問題要處理。

libGL.so 在 DRI 架構裡扮演了 loader 的角色,它跑在 client 這邊。就像 OpenGL 與平台無關一樣,DRI driver 也與平台無關。loader 一方面載入 DRI driver,一方面又提供適當的 hook 讓 DRI driver 呼叫,並實作了平台相關的部份。所以在 DRI driver 真的要用到 buffer 的時候,它會呼叫 loader 的 getBuffers 函數取得視窗的 buffer 與大小。libglx.so 跟 libdri2.so 實作了 GLX 與 DRI2 這兩個 X extensions。在 X 的平台上,對於 DRI driver 的要求,libGL.so 會利用 GLX 與 DRI2 協定取得所需的資訊,並傳回給 DRI driver。

一個快速驗證上面說法的方法是直接檢視系統的 /usr/lib/libGL.so 跟 /usr/lib/dri/i915_dri.so。libGL.so 只是 loader,檔案大小應該要比 i915_dri.so 小不少;而 i915_dri.so 與平台無關,所以 ldd 應該不會看到 X11 的函式庫。如果再進一步想,那是不是只要提供適當的 loader,DRI driver 也能用在 X 以外的平台?答案是肯定的。

在 compiz 剛出來的時候,有很多名詞跟著它一起冒出來。像是 XGL、GLX_EXT_texture_from_pixmap、還有 AIGLX 等。在 libGL.so 無法成功跟 X server 溝通使用 DRI 時,client 的 3D 繪圖指令會改經由 GLX 傳給 server 處理,這被稱作 indirect rendering。在早先,libglx.so 會利用純軟體的方式執行這些 3D 指令,所以 indirect rendering 跟 software rendering 是等價的。這個情形在 AIGLX 引入後有很大的改變。在 AIGLX 下,libglx.so 除了提供 GLX extension 實作外,它同時也是一個 DRI loader,可以利用 DRI driver 進行 3D 加速。因為 AIGLX,indirect rendering 不再直接被視為慢、無法接受,雖然它還是多了 client 到 server 的 overhead。AIGLX 即是 Accelerated Indirect GLX 的縮寫,非常直接。

因為我直接從 DRI2 開始看,無法比較它跟 DRI1 的差異。在 DRI2 作者 Kristian Høgsberg 的 blog 可以找到一些關鍵字。Kristian Høgsberg 同時也是之前文章提到的 Wayland 的作者。

Friday, January 30, 2009

一千零一夜之 Console I/O

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

當一個程式被執行時,它的 stdin/stdout/stderr 會從父程序繼承。如果沒有特別指定,它們通常會指向同一個諸如 /dev/ttyX 或 /dev/pts/X 的 TTY device。很難不去好奇,當我們 getchar() 或 printf() 時,對一個 TTY device 的 I/O,在 kernel 裡頭會發生什麼事?



口語裡的 console,指的通常是圖中 VT。VT 是 virtual terminal 的縮寫,對 userspace 來說,它就像是一部真實存在著的終端機;在 kernel 裡頭,VT(的功能之一)是一個 TTY driver,它是所有 /dev/ttyX 裝置的驅動程式。對 TTY device 的 I/O 動作,會經由 TTY core 送給 TTY driver。資料往來於 TTY 與 TTY driver 的過程中,或者說圖中連結 TTY 與 VT 的線,被稱做 TTY ldisc,TTY line discipline。

在之前的文章中我們看到鍵盤向 TTY 送出的資料。來自於鍵盤的輸入,可能是特別的按鍵組合,目的並不是讓 userspace 去取得這些輸入。例如,我們會敲下 Ctrl-C 來中斷目前的程式;Ctrl-Z 來暫停目前的程式。又或者,我們不希望輸入的密碼會出現在螢幕上。這些需求都在 line discipline 中被滿足。因為所有的 I/O 都會經由 line discipline,於是它可以在使用者輸入特定字元時,對目前的程式送出 SIGINT 或 SIGTSTP;它也可以選擇是否要把使用者的輸入再 echo 回 VT。從這邊也可以看到,line discipline 不只可以對資料做緩衝與處理,它還被允計針對特定的輸入做特定的行為。當我們從 VT 換到實體的 COM port 時,且當與 COM port 連結的裝置不是終端機,而是數據機時,line discipline 甚至可以拒絕所有來自 userspace 的 I/O,轉而從 PPP network device 與 userspace 做資料交換。實際上,TTY device 只是一個 transport layer,可以跟它連結的裝置千變萬化。line discipline 於是也被設計成可以抽換;當從終端機換成數據機時,line discipline 也從 N_TTY 換成 N_PPP。

跟來自鍵盤的輸入一樣,使用者對 TTY device 寫入的資料,會經過 line discipline,VT,再進入螢幕。在 drivers/char/n_tty.c 的 do_output_char 函數中
switch (c) {
...
case '\r':
if (O_ONOCR(tty) && tty->column == 0)
return 0;
if (O_OCRNL(tty)) {
c = '\n';
if (O_ONLRET(tty))
tty->canon_column = tty->column = 0;
break;
}
tty->canon_column = tty->column = 0;
break;
case '\t':
spaces = 8 - (tty->column & 7);
if (O_TABDLY(tty) == XTABS) {
if (space <>column += spaces;
tty->ops->write(tty, " ", spaces);
return spaces;
}
tty->column += spaces;
break;
...
}

可以看到 line discipline 會對特殊字元,像是換行符號或 tab 等做排版。更多關於 N_TTY 這個 line discipline 的功能可以參考 stty(1)。

VT 的架構與實體的 terminal 與 host computer 架構是對應的。要把現在手上正在上網的電腦想像成它是 terminal 與 host computer 的組成可能不是那麼容易。一個相對常見、具體的情境,是用一條線把手上的電腦與 wifi router 或手機的 UART console 連結。上圖中的 Computer B 可以理解成手上的電腦,Computer A 則是跑著 linux 的嵌入式系統。

Tuesday, January 27, 2009

一千零一夜之 keyboard in console

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

按下或放開按鍵的時候,鍵盤會產生一段長度不等的 scancode,這段 scancode 會被 keyboard driver (像是 drivers/input/keyboard/atkbd.c) 處理,轉換成類型為 EV_MSC 與 EV_KEY 的 input event。EV_MSC 事件的內容是 scancode 本身,與硬體直接相關且不容易處理,除非有特殊需求,通常我們比較關心的是 EV_KEY input event。想要處理這些事件的其它子系統,可以向 input layer 註冊 input handler。例如 evdev 會註冊一個 input handler 讓 userspace 可以從 /dev/input/eventX 直接取得鍵盤事件。kernel 的 console driver 也會向 input layer 註冊一個 handler 來取得鍵盤事件,這是我們這次想要比較深入了解的項目。

console 跟鍵盤的交互作用可以在 drivers/input/char/keyboard.c 看到。在 console 底下,鍵盤有四種模式,

#define VC_XLATE 0 /* translate keycodes using keymap */
#define VC_MEDIUMRAW 1 /* medium raw (keycode) mode */
#define VC_RAW 2 /* raw (scancode) mode */
#define VC_UNICODE 3 /* Unicode mode */

可以利用 kbd_mode 命令來切換。前面有提到 keyboard driver 會送出 EV_MSC 與 EV_KEY 兩種 input event,其中前者送出的 scancode 被用來實作 VC_RAW 模式;後者送出的 keycode,則可以用來實作 VC_MEDIUMRAW 模式。剩下的兩種模式都是 keycode 的再加工。

scancode 到 keycode 的轉換透過了 keyboard driver 定義的 keycode table 完成。在 atkbd.c 裡,如果忽略掉其它細節,它只是簡單的

keycode = atkbd->keycode[code];

一行程式碼。有些多媒體鍵盤會有一些按鍵的 scancode 不在預設的 keycode table 裡,當這些按鍵被按下或放開的時候,kernel 會印出類似

atkbd.c: Unknown key pressed (translated set 2, code 0x1e on isa0060/serio0).
atkbd.c: Use 'setkeycodes 1e <keycode>' to make it known.

的訊息。依照這段訊息提示的方法去做

# setkeycodes <scancode> <keycode>

就可以新增一筆對映的資料。setkeycodes 與 getkeycodes 命令即是用來設定或取得目前的 keycode table。值得注意的是,大部份的 keycode 有對應的 symbolic name,例如 keycode 30 的 symbolic name 是 KEY_A,keycode 48 的是 KEY_B,keycode 46 的是 KEY_C 等 (見 /usr/include/linux/input.h)。這些 symbolic name 是照美式鍵盤定義而來,拿到其它語言的鍵盤上並沒有意義。

console 下 keyboard 預設的模式是 VC_XLATE 或 VC_UNICODE。從 input layer 拿到 keycode 後,console 會呼叫 kbd_event 函數做處理。在這兩個模式下,keycode 會被轉換成 keysym

key_map = key_maps[shift_final];
...
keysym = key_map[keycode];

然後 queue 到 console buffer。stdin 接到 console 的程式即是由這邊取得使用者的輸入。這個動作會經過 line discipline,不過我們這邊不去討論。

一個 keysym 是兩個 byte,分別可以由 KTYP(keysym) 跟 KVAL(keysym) 取得它的 type 與 value。當 type 小於 0xf0 時,整個 keysym 代表一個 UCS2 的 codepoint,keysym 會被轉成 UTF-8 放進 console buffer;當 type >= 0xf0 時,與 type 相關的 handler 被呼叫,其 prototype 為

typedef void (k_handler_fn)(struct vc_data *vc, unsigned char value,
char up_flag);

其中 value 就是剛剛看到的 KVAL(keysym)。有些 handler 會把處理過的 value 寫入 console buffer,有些則不會,這樣設計的目的以例子來看最容易理解。我們知道 shift 按著的時候,所有的字母大小寫會互換。當 shift 的按下時,鍵盤控制器送出中斷,keyboard driver 收到後把 scancode 讀出並轉成 keycode,送出 input event。console 收到 event 後利用 keymap 把 keycode 轉成 keysym。shift 的 keysym type 是 0xf7,value 是 0x00,送到對應的 handler 中

if (up_flag) {
if (shift_down[value])
shift_down[value]--;
} else
shift_down[value]++;

if (shift_down[value])
shift_state |= (1 << value);
else
shift_state &= ~(1 << value);

可以發現 shift_state 的第一個 bit 被設為 1。shift_state 是 keyboard.c 裡的 file-scope 變數,當任何一個按鍵再被按下時,kbd_event 裡這一段程式碼

shift_final = (shift_state | kbd->slockstate) ^ kbd->lockstate;
key_map = key_maps[shift_final];

選取了不同的 keymap,導致或許不一樣的 keysym 被送出,本來是小寫的英文字母也因而變成大寫。

在 kernel 內部實作,console 使用的是 UCS2 編碼。不管是使用者列印到 console 的字串,或者是 keysym 的 value 都會先重新編碼成 UCS2 再做進一步處理。在 VC_UNICODE 模式底下,UCS2 會以 UTF-8 形式被送進 console buffer;在 VC_XLATE 模式,則會嘗試再編碼回原來的 value 送到 console buffer。

相對於 keymap 複雜的機制,它的操作卻非常簡單。在 userspace 可以利用 loadkeys 與 dumpkeys 命令來操作 keymaps

# loadkeys de # 使用德式鍵盤 layout
# loadkeys us # 使用美式鍵盤 layout

進一步的資訊可以參考 keymaps(5)。

這篇文章我們看到了鍵盤在 console 的運作。如果換到 X(org) server,情形有點不同,而且也因驅動程式而異。例如 xf86-input-keyboard 雖然是從 console 取得鍵盤事件,但它會把 console 設為 VC_RAW 模式,自行處理 scancode。而 xf86-input-evdev 則是直接從 /dev/input/eventX 取得鍵盤事件。以後有機會也可以看看 X(org) 下的鍵盤運作。

Friday, December 26, 2008

一千零一夜之 BitBake Data class

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。

曾經使用過 OpenEmbedded 的開發者應該可以想像,當 bitbake my-app 被執行時,它會去做哪些事。例如,它可能會去讀 conf 檔,然後利用這資料 (e.g., PREFERRED_PROVIDER of my-app) 決定要用哪個 bb 檔。當然 bb 檔可能會 inherit 某個 class 檔或者 include 某個 inc 檔。等到需要的資料都讀進來了,bitbake 就可以開始 unpack、pack、configure 等去逐一執行這個 bb 檔所指定的各 task。如果暫時不去理會 cache、相依性或者某 bb 檔指定的某檔案是怎麼抓下來,這個想像也就是 bitbake 核心的功能之一,也是這篇文章感興趣的項目:BitBake Data class。

以 glib-2.0-native_2.16.1.bb 為例,

require glib-2.0_${PV}.bb

FILESPATH = "${FILE_DIRNAME}/glib-2.0-${PV}:${FILE_DIRNAME}/files"
DEPENDS = "gtk-doc-native"
PR = "r2"

inherit native

do_configure_prepend() {
if [ -e ${S}/${TARGET_SYS}-libtool ] ; then
echo "${TARGET_SYS}-libtool already present"
else
cp ${STAGING_BINDIR}/${TARGET_SYS}-libtool ${S}
fi
}

do_stage () {
...
}

...

可能看出 bb 檔在做的事,主要是設定變數以及定義函數 (python or shell script)。Data class 就是用來紀綠 bitbake 從各設定檔跟 bb 檔讀進來各個變數的值。特別值得注意的是,對 Data class 來說,函數跟變數並沒有太大的不同。或者說,函數只是比較特別一點的變數。在上面的例子裡,do_stage() 其實只是定義了一個叫做 do_stage 的變數,而它的值剛好是一段 shell script。bb 檔裡還會出現一些 keyword (require, inherit 等),parser 在看到它們的時候,不一定是利用 Data class 來紀錄這些資訊。

在了解 bitbake 怎麼處理變數前我們必須先知道 Data class 提供了哪些機制。我們知道 Data class 是用來紀錄 key-value pairs 用的。又,上面提到有些變數是特殊的,所以每個 key 勢必還要有 flag 來描述其性質 (是不是可以執行,可執行的話是 python or shell script 等)。為了達到這個需求,實作上 Data class 是一個 dict of dict。也就是說,

DEPENDS = "gtk-doc-native"
S = "${WORKDIR}/git"
FILES_${PN}-locale = "${datadir}/locale"

會以

d.dict['DEPENDS']['content'] = 'gtk-doc-native'
d.dict['S']['content'] = '${WORKDIR}/git'
d.dict['FILES_${PN}-locale']['content'] = '${datadir}/locale'

的形式存到 d (an instance of class Data) 裡面。而

do_stage () { some_code }

則會變成

d.dict['do_stage']['content'] = 'some_code'
d.dict['do_stage']['func'] = '1'

利用 dict of dict,Data class 輕易地為任何的 key 提供任意多的性質。

我們知道了 Data class 讓我們可以為任意的 key 標上任意的性質,但 bitbake 的需求不僅僅只是如此。更重要的是,bitbake 想提供的是變數的處理。從上面的例子可以看到,S = "${WORKDIR}/git" 進到 Data class 裡是 d['S']['content'] = '${WORKDIR}/git' 的形式,WORKDIR 這個變數並沒有被展開。Data class 在變數展開方面採用的是 lazy 的策略。也就是說變數的展開,會在讀值的時候發生。所以要等到稍後某個 task 取 S 的值時
cd ${S}

WORKDIR 才會被即時展開。

變數除了可以出現在 value 外也可以出現在 key 的部份 (如 FILES_${PN}-locale)。不同的是,key 的變數展開發生在 d.expandKeys(),而且是不可復原的。它的目的跟我們最後想看的 prepend/append/override 有關。

在 bb 檔裡頭不難看到

do_configure_prepend() { some_code }
do_install_append() { some_other_code }
TARGET_FPU_arm = "soft"

等語法。這讓開發者可以很輕易地在 task 開始或結束的地方加上一段 script,或者讓開發者可以有條件地設定某個變數。例如,我們可能希望當目標架構是 arm 時把 TARGET_FPU 設成 soft。上面這些語法在 Data class (不完全正確) 的作法是

d.dict['do_configure']['_prepend'].append('some_code')
d.dict['do_install']['_append'].append('some_other_code')
d.dict['TARGET_FPU_arm']['content'] = 'soft'


而 prepend/append/override 發生的時機,不像變數展開是在取值時即時發生,也不像變數展開並不會去修改 d 的值,prepend/append/override 只有在 d.update_data() 時才會發生,而且修改也不可復原。例如當目標架構是 arm 時,TARGET_FPU 會被 override 成 TARGET_FPU_arm 的值

d.dict['TARGET_FPU'] = d.dict['TARGET_FPU_arm']

Override 機制比這邊討論的略為複雜一些。有興趣的人建議可以直接參考實作。

BitBake parser 規範了 bb 檔的語法。但部份 parser 允許的操作並不被 Data class 直接支援。最後,不妨猜猜看 ?=, :=, += 等操作跟 Data class 如何相互作用?

Sunday, December 14, 2008

一千零一夜之 DRI

這個系列是讀書筆記,作者可能沒有跟主題有關的開發經驗。


DRI 讓 X clients 可以直接利用硬體來做繪圖,這點可以利用下面指令看出來:

olvaffe@m500:~$ glxgears &
[1] 24684
olvaffe@m500:~$ cat /proc/24684/maps
08048000-0804b000 r-xp 00000000 08:03 80591 /usr/bin/glxgears
0804b000-0804c000 rw-p 00002000 08:03 80591 /usr/bin/glxgears
...
b38fa000-b58fa000 rw-s e6000000 00:0d 7315 /dev/dri/card0
b58fa000-b62fa000 rw-s e5000000 00:0d 7315 /dev/dri/card0
b62fa000-b6cfa000 rw-s e4000000 00:0d 7315 /dev/dri/card0
b6cfa000-b733a000 rw-s 2c200000 00:0d 7315 /dev/dri/card0
b733a000-b797a000 rw-s 2c200000 00:0d 7315 /dev/dri/card0
...
b79a0000-b7bbd000 r-xp 00000000 08:03 347365 /usr/lib/dri/i915_dri.so
b7bbd000-b7bd1000 rw-p 0021c000 08:03 347365 /usr/lib/dri/i915_dri.so
b7c00000-b7c07000 r-xp 00000000 08:03 66335 /usr/lib/libdrm.so.2.3.1
b7c07000-b7c08000 rw-p 00006000 08:03 66335 /usr/lib/libdrm.so.2.3.1
b7eb5000-b7f11000 r-xp 00000000 08:03 69724 /usr/lib/libGL.so.1.2
b7f11000-b7f17000 rw-p 0005b000 08:03 69724 /usr/lib/libGL.so.1.2
...

我們可以看到,glxgears 把 i915_dri.so (intel 的 driver) 載進來並且開啟了 /dev/dri/card0。而在不使用 DRI 的時候:

olvaffe@m500:~$ LIBGL_ALWAYS_INDIRECT=1 glxgears &
[1] 24834
olvaffe@m500:~$ cat /proc/24834/maps
08048000-0804b000 r-xp 00000000 08:03 80591 /usr/bin/glxgears
0804b000-0804c000 rw-p 00002000 08:03 80591 /usr/bin/glxgears
...
b7bd3000-b7bda000 r-xp 00000000 08:03 66335 /usr/lib/libdrm.so.2.3.1
b7bda000-b7bdb000 rw-p 00006000 08:03 66335 /usr/lib/libdrm.so.2.3.1
...
b7e88000-b7ee4000 r-xp 00000000 08:03 69724 /usr/lib/libGL.so.1.2
b7ee4000-b7eea000 rw-p 0005b000 08:03 69724 /usr/lib/libGL.so.1.2
...

則少了上述的檔案。這是因為繪圖方面都轉送給 X server 去處理。如果用 CPU usage 去看,也可以看出在這兩個情形下,比較忙的可能是 server 或著是 client。而就像 client 可以利用 DRI 做加速一樣,X server 在收到 client 的請求時,也可以利用 DRI 去完成這些請求,這個技術被稱為 AIGLX (Accelerated Indirect GLX)。

從上面的例子我們可以看出 DRI 這個架講的基本組成份子:提供 /dev/dri/card0 的 i915 kernel module、存取這個裝置用到的 libdrm、Mesa 提供的 libGL 與 i915_dri.so、最後 X server 那邊提供了 GLX 跟 DRI server extensions。值得一提的是,X server 這邊雖然沒有用到 libGL,但它其實用到了部份 Mesa 的 source 來實作 GLX 跟 DRI server extensions,在 AIGLX 的情況下,甚至會 dlopen i915_dri.so 來用。