GTK DirectFB PC模擬執行環境

2021-04-14 07:19:33 字數 1289 閱讀 3740

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...