GTK DirectFB PC模擬執行環境

gtk+/directfb pc模擬執行環境

基於sdl/x11等其它gui

這個很簡單，只要修改一下directfb的配置/etc/directfbrc即可(也可以修改當前使用者的配置檔案)。如：

system=sdl

mode=240x320

wm=unique

這裡的system=sdl指定以sdl作為顯示後端，sdl通常是執行在x11之上的，所以要注意設定display環境變數。mode=240x320指明解析度為240畫素寬，320畫素高。wm=unique指定視窗管理器為unique。

基於framebuffer

如果前面的方式能夠正常工作，那就沒有必要使用基於framebuffer方式了。但不幸的是前面的方式在多程序(基於fusion)時，非常容易死鎖，這主要是因為呼叫fusion_call_execute更新螢幕引起的。這個問題在最新版本裡，似乎也沒有解決，我看了一下，要解決它也確實很麻煩。

基於framebuffer是唯一不會死鎖的方式，所以在多程序執行時使用基於framebuffer的方式是比較明智的。但遺憾的是，pc上的framebuffer的解析度一般在都640x480及以上大小（可以參考kernel中的文件documentation/fb/vesafb.txt）。看了網上一些文件，也做了一些嘗試，但沒有成功的把解析度設定得更低。

後來修改了一下directfb，讓它把視窗顯示到指定區域，這樣雖然framebuffer的解析度是比較大的，但是螢幕上的效果是可以是任意解析度的。主要修改如下：

1.修改layer_context.c:dfb_layer_context_get_configuration，返回配置檔案中指定的解析度，而不是實際的解析度。因為gdk_screen_width/gdk_screen_height呼叫該函式獲得螢幕大小，修改之後，gdk認為螢幕大小是配置檔案中指定的值，而不是實際的framebuffer的大小。

2.修改視窗管理器的wm_resize_stack函式(也可以修改呼叫的地方)，使用配置檔案中指定的解析度，而不是實際的解析度。這樣視窗管理器可以據此約束視窗的顯示範圍(與視窗管理器的實現有關)。

測試了一下，發現基於framebuffer的pc版本穩定多了，再也沒有出現過那種死鎖現象，解析度也可以設定為任意大小。

不過要注意的是，基於framebuffer的directfb獨佔了顯示裝置，你不能執行其它x11程式，也不能開啟終端，只能通過ssh遠端去控制它。為了方便，把它放到虛擬機器裡去執行是不錯的選擇。

GTK DirectFB PC模擬執行環境

gtk directfb pc模擬執行環境 基於sdl x11等其它gui 這個很簡單，只要修改一下directfb的配置 etc directfbrc即可 也可以修改當前使用者的配置檔案 如 system sdl mode 240x320 wm unique 這裡的system sdl指定以sdl...

GTK DirectFB PC模擬執行環境

gtk directfb pc模擬執行環境 基於sdl x11等其它gui 這個很簡單，只要修改一下directfb的配置 etc directfbrc即可 也可以修改當前使用者的配置檔案 如 system sdl mode 240x320 wm unique 這裡的system sdl指定以sdl...

GTK DirectFB PC模擬執行環境

gtk directfb pc模擬執行環境 基於sdl x11等其它gui 這個很簡單，只要修改一下directfb的配置 etc directfbrc即可 也可以修改當前使用者的配置檔案 如 system sdl mode 240x320 wm unique 這裡的system sdl指定以sdl...