Qt/Embedded在嵌入式Linux系统中的应用

   关键词：

引言

随着嵌入式linux应用的不断发展，嵌入式处理器运算能力的不断增强，越来越多的嵌入式设备开始采用较为复杂的gui系统，手持设备中的gui系统发展得非常迅速。传统的gui系统，如microwindows等，由于项目规模较小、功能较为薄弱，缺乏等三方软件开发的支持等诸多原因，在比较高级的手持或移动终端设备（如pda、smart-phone、车载导航系统）中应用较少。

qt/embedded是著名的qt库开发商trolltech公司开发的面向嵌入式系统的qt版本，开发人员多为kde项目的核心开发人员。许多基于qt的x window程序可以非常方便地移植到qt/embedded上，与x11版本的qt在最大程度上接口兼容，延续了在x上的强大功能，在底层彻底摒弃了x lib，仅采用framebuffer作为底层图形接口。qt/embedded类库完全采用c++封装。丰富的控件资源和较好的可移植性是qt/embedded最为优秀的一方面，使用x下的开发工具qt designer可以直接开发基于qt/embedded的ui（用户操作接口）界面。越来越多的第三方软件公司也开始采用qt/embedded开发嵌入式linux下的应用软件。其中非常著名的qt palmtop environment（qtopia）早期是一个第三方的开源项目，并已经成功应用于多款高档pda。trolltech公司针对smart-phone中的应用需求，于2004年5月底发布了qtopia的phone版本。

1 qt/embedded的实现技术基础分析

横向来看，由于发布的版权问题，qt/embedded采用两种方式进行发布：在gpl协议下发布的free版与专门针对商业应用的commercial版本。二者除了发布方式外，在源码上没有任何区别。纵向看来，当前主流的版本为qtopia的2.x系列与最新的3.0x系列。其中2.0版本系统较多地应用于采用qtopia作为高档pda主界面的应用中；3.x版本系列则应用于功能相对单一，但需要高级gui图形支持的场合，如volvo公司的远程公交信息系统。图1为qt/embedded的实现结构。

3.x版本系列的qt/embedded相对于2.x版本系统增加了许多新的模块，如sql数据库查询模块等。几乎所有2.x版本中原有的类库，在3.x版本中都得到极大程度的增强。这就极大地缩短了应用软件的开发时间，扩大了qt/embedded的应用范围。

    在代码设计上，qt/embedded巧妙地利用了c++独有的机制，如继承、多态、模板等，具体实现非常灵活。但其底层代码由于追求与多种系统、多种硬件的兼容，代码补丁较多，风格稍显混乱。

1．1 qt/embedded的图形引擎实现基础

qt/embedded的底层图形引擎基于framebuffer。framebuffer是在linux内核架构版本2.2以后推出的标准显示设备驱动接口。采用mmap系统调用，可以将framebuffer的显示缓存映射为可连续访问的一段内存储针。由于目前比较高级的arm体系的嵌入式cpu中大多集成了lcd控制模块，lcd控制模块一般采用双dma控制器组成的专用dma通道。其中一个dma可以自动从一个数据结构队列中取出并装入新的参数，直到整个队列中的dma操作都已完成为止。另外一个dma与画面缓冲区相关，这部分由两个dma控制器交替执行，并每次都自动按照预定的规则改变参数。虽然使用了双dma，但这两个dma控制器的交替使用对于cpu来说是不可见的。cpu所获得的只是由两个dma组成的一个“通道”而已。

framebuffer驱动程序的实现分为两个方面：一方面是对lcd及其相关部分的初始化，包括画在缓冲区的创建和对dma通道的设置；另外一方面是对画面缓冲区的读写，具体到代码为read、write、lseek等系统调用接口。至于将画面缓冲区的内容输出到lcd显示屏上，则由硬件自动完成。对于软件来说是透明的。当对于dma通道和画面缓冲区设置完成后，dma开始正常工作，并将缓冲区中的内容不断发送到lcd上。这个过程是基于dma对于lcd的不断刷新的。基于该特性，framebuffer驱动程序必须将画面缓冲区的存储空间（物理空间）重新映射到一个不加高缓存和写缓存的虚拟地址区间中，这样能才保证应用程序通过mmap将该缓存映射到用户空间后，对于该画面缓存的写操作能够实时的体现在lcd上。

在qt/embedded中，qscreen类为抽象出的底层显示设备基类，其中声明了对于显示设备的基本描述和操作方式，如打开、关闭、获得显示能力、创建gfx操作对象等。另外一个重要的基类是qgfx类。该类抽象出对于显示设备的具体操作接口（图形设备环境），如选择画刷、画线、画矩形、alpha操作等。以上两个基类是qt/embedded图形引擎的底层抽象。其中所有具体函数基本都是虚函数，qt/embedded对于具体的显示设备，如linux的framebuffer、qt virtual framebuffer做的抽象接口类全都由此继承并重载基类中的虚函数实现。图2为qt/embedded中底层图形引擎实现结构。

图2

    在图2中，对于基本的framebuffer设备，qt/embedded用qlinuxfbscreen来处理。针对具体显示硬件（如mach卡、voodoo卡）的加速特性，qt/embedded从qlinuxfbscreen和图形设备环境模板类qgfxraster<depth,type>继承出相应子类，并针对相应硬件重载相关虚函数。

qt/embedded在体系上为c/s结构，任何一个qt/embedded程序都可以作为系统中唯一的一个gui server存在。当应用程序首次以系统gui server的方式加载时，将建立qwsserver实体。此时调用qwsserver::opendisplay()函数创建窗体，在qwsserver::opendisplay（）中对qwsdisplay：：data中的init()加以调用；根据qgfxdriverfactory实体中的定义（qlinuxfbscreen）设置关键的qscreen指针qt_screen并调用connect()打开显示设备（dev/fb0）。在qwsserver中所有对于显示设备的调用都由qt_screen发起。至此完成了qt/embedded中qwsserver的图形发生引擎的创建。当系统中建立好gui server后，其它需要运行的qt/embedded程序在加载后采用共享内存及有名管道的进程通信方式，以同步访问模式获得对共享资源framebuffer设备的访问权。

1.2 qt/embedded的事件驱动基础

qt/embedded中与用户输入事件相关的信号，是建立在对底层输入设备的接口调用之上的。qt/embedded中的输入设备，分为鼠标类与键盘类。以3.x版本系列为例，其中鼠标设备的抽象基类为qwsmouse handler，从该类又重新派生出一些具体的鼠标类设备的实现类。该版本系列的qt/embedded中，鼠标类设备的派生结构如图3所示。

与图形发生引擎加载方式类似的，在系统加载构造qwsserver时，调用qwsserver::openmouse与qwsserver::openkeyboard函数。这两个函数分别调用qmousedriverfactory::cr-eate()与qkbddriverfactory::cr-eate()函数。这时会根据linux系统的环境变量qws_mouse_proto与qws_keyboard获得鼠标类设备和键盘类设备的设备类型和设备节点。打开相应设备并返回相应设备的基类句柄指针给系统，系统通过将该基类指令强制转换为对应的具体子类设备指针，获得对具体鼠标类设备和键盘类设备的调用操作。

值得注意的是，虽然几乎鼠标类设备的功能上基本一致，但由于触摸屏和鼠标底层接口并不一样，会造成对上层接口的不一致。举例来讲，从鼠标驱动接口中几乎不会得到绝对位置信息，一般只会读到相对移动量。另外，鼠标的移动速度也需要考虑在内，而触摸屏接口则几乎是清一色的绝对位置信息和压力信息。针对此类差别，qt/embedded将同一类设备的接口部分也给予区别和抽象，具体实现在qmousedriverinterface类中。键盘类设备也存在类似问题，同样引入了qkbddriver inteface来解决。具体实现此处暂不多述。

2 qt/embedded的移植与应用

针对qt/embedded的实现特点，移植该嵌入式gui系统一般分为以下几个步骤：

①设计硬件开发平台，并移植linux操作系统；

②采用静态链接进linux内核的方式，根据该平台显示设备的显示能力，开发framebuffer驱动程序；

③开发针对该平台的鼠标类设备驱动程序，一般为触摸屏或usb鼠标；

④开发针对该平台的键盘类设备驱动程序，一般为板载按钮或usb键盘（该部分可选）；

⑤根据framebuffer驱动程序接口，选择并修改qt/embedded中的qlinuxfbscreen和qgfxraster类；

⑥根据鼠标类设备驱动程序，实现该类设备在qt/embedded中的操作接口；

⑦根据键盘类设备驱动程序，实现该类设备在qt/embedded中的操作接口（该部分可选）；

⑧根据需要选择qt/embedded的配置选项，交叉编译qt/embedded的动态库；

⑨交叉编译qt/embedded中的example测试程序，在目标平台上运行测试。

framebuffer设备驱动程序提供出的接口是标准的，除了注意endian问题外，配置qt/embedded时选择相应的色彩深度支持即可，因此该部分的移植难点就在于framebuffer驱动程序的实现。qt/embedded部分的qwsserver打开/dev/中的framebuffer设备后读出相应的显示能力（屏幕尺寸、显示色彩深度），模板qgfxraster<depth.type>将根据色彩深度在用户空间设备创建出与显示缓存同样大小的缓冲作为双缓冲，并采用正确方式进行显示。

    2.1 在pxa255平台上移植和应用

在笔者参与设计的某smart-phone开发平台中，gui系统实现方案采用了qt/embedded 2.3.7和qtopia 1.7.0（基于qt/embedded 2.x系列的手持套件），硬件平台采用了基于intel xscale pxa255处理器的嵌入式开发系统。该开发系统采用640×480分辨率的tft lcd和pxa255内部lcd控制模块作为显示设备，ads7846n作为外部电阻式触摸屏控制器；另外，采用了五方向按键作为板载键盘。由于该系统采用了isp1161作为usb host控制器，较好地支持了usb接口的键盘和鼠标，操作系统为arm linux 2.4.19。参考linux 2.4.19内核目录drivers/input部分，可以按照标准内核中input device接口设计实现触摸屏和键盘，在实现了基于isp1161的ehci驱动程序后，移植标准的usb接口的人机界面设备驱动hid和usb键盘、鼠标的驱动程序后，可以获得对于该类设备的调用接口。此过程不属本文讨论范畴，此处暂不多述。

qt/embedded 2.x系列对于输入设备的底层接口与3.x系列不同，触摸屏设备和键盘设备需要根据具体的驱动程序接口在qt/embedded中设备实现对应的设备操作类。其中