GTK+/DirectFB PC模拟运行环境
转载时请注明出处和作者联系方式
作者联系方式：李先静 <xianjimli at hotmail dot com>
GTK+/DirectFB不但可以运行在frambebuffer上，而且可以运行在其它GUI之上，比如像SDL和X11等等，因此在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远程去控制它。为了方便，把它放到虚拟机里去运行是不错的选择。
~~end~~