李先静的专栏

转载时请注明出处和作者联系方式
作者联系方式：李先静 <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~~

发表于 @ 2007年11月12日 20:54:00|评论(loading...)|编辑|收藏

新一篇: 当老爸了 | 旧一篇: 音频处理介绍(Linux手机)

#xydarcher 发表于2007-12-08 16:44:00 IP: 218.194.60.*: 老兄有没有想过试试qvfb呢？

#pilgrim_kevin 发表于2007-12-14 22:07:59 IP: 116.77.162.*: 我最近在做DirectFB+GTK+在arm上的移植。交叉编译很顺利，写编译脚本+编译一天多就完成了，但是在板上的运行有问题，目前为止举步维艰。有做过或有兴趣的朋友，希望能找到人交流。

到目前为止两个比较难搞的问题是：

1。板子是Faraday8120方案（arm9核FA526CPU+DSP双核），内核2.14.19，使用Faraday的framebuffer和 LCD驱动，色彩模式是YUV420。DirectFB lib运行时自动设定色彩模式为16bitRGB16，看了一下代码，自己加入了YUV420(YV12)的一些代码，暂时pass。因为有后面的错误，所以不知道这个问题到底是否pass。

2。解决了前面的问题，后面出现Caught signal 11错误，某个地址invalid permission，没有什么其他的错误信息，这个比较头大，到现在为止不知如何着手。

自己写的framebuffer测试程序和视频解码播放程序均能正常在屏上显示，都将YUV420数据（解码或视频捕捉或原始YUV420数据文件）直接输出到framebuffer显示。

老大看见的话，指教一下。