图形嵌入式Linux系统的图形用户界面

作者魏永明ymw ei@minigui.org。

声明任何人可以以任何方式复制、修改发布或者转贴这篇文章的部分或全部内容前提是完整保留这一版权声明。如果要修改本文或者作为其他可发布稿件的部分请通过电子邮件通知原作者。当然如果发现其中的任何错误也请告诉原作者 以便修改更新。目录

1 Linux图形领域的基础设施

1.1 X Window

1.2 SVGALib

1.3 FrameBuffer

1.4 LibGGI

2 Linux图形领域的高级函数库

2.1 Xlib及其他相关函数库

2.2 SDL

2.3 Allegro

2.4 Mesa3D

2.5 DirectFB

3面向嵌入式Linux系统的图形用户界面

3.1 MicroWindows/NanoX

3.2 OpenGUI

3.3 Qt/Embedded

3.4 MiniGUI

4小结

本文首先概述了Linux图形领域的基本设施然后描述了一些可供嵌入式Linux系统使用的高级图形库以及图形用户界面支持系统。希望对嵌入式Linux系统的开发有所帮助。1 Linux图形领域的基础设施

本小节首先向读者描述Linux图形领域中常见的基础设施。之所以称为基础设施是因为这些系统或者函数库一般作为其他高级图形或者图形应用程序的基本函数库。这些系统或者函数库包括 X Window、 SVGALib、 FrameBuffer等等。

1.1 X Window

提起Linux上的图形许多人首先想到的是X Window。这一系统是目前类UNIX系统中处于控制地位的桌面图形系统。无疑X Window作为一个图形环境是成功的它上面运行着包括CAD建模工具和办公套件在内的大量应用程序。但必须看到的是 由于XWindow在体系接口上的原因限制了其对游戏、多媒体的支持能力。用户在X Window上运行VCD播放器或者运行一些大型的三维游戏时经常会发现同样的硬件配置却不能获得和Window s操作系统一样的图形效果――即使使用了加速的X Server其效果也不

能令人满意。另外大型的应用程序比如Mozilla浏览器在X Window上运行时的响应能力也相当不能令人满意。当然这里有L inux 内核在进程调度上的问题也有XWindow的原因。

X Window为了满足对游戏、多媒体等应用对图形加速能力的要求提供了DGA直接图形访问扩展通过该扩展应用程序可以在全屏模式下直接访问显示卡的帧缓冲区并能够提供对某些加速功能的支持。

1.2 SVGALib

S VG AL ib是Linux系统中最早出现的非X图形支持库。这个库从最初对标准VG A兼容芯片的支持开始一直发展到对老式SVGA芯片的支持以及对现今流行的高级视频芯片的支持。它为用户提供了在控制台上进行图形编程的接口使用户可以在PC兼容系统上方便地获得图形支持。但该系统有如下不足

1接口杂乱。 SVGALib从最初的vgalib发展而来保留了老系统的许多接口而这些接口却不能良好地迎合新显示芯片的图形能力。

2未能较好地隐藏硬件细节。许多操作不能自动使用显示芯片的加速能力支持。

3可移植性差。SVGALib 目前只能运行在x86平台上对其他平台的支持能力较差Alpha平台除外。

4发展缓慢有被其他图形库取代的可能。 SVGALib作为一个老的图形支持库 目前的应用范围越来越小尤其在Linux 内核增加了Fr am eBuffer驱动支持之后有逐渐被其他图形库替代的迹象。

5 对应用的支持能力较差。 S VAGL ib作为一个图形库对高级图形功能的支持 比如直线和曲线等等却不能令人满意。尽管SVGALib有许多缺点但SVGALib经常被其他图形库用来初始化特定芯片的显示模式并获得映射到进程地址空间的线性显示内存首地址即帧缓冲区而其他的接口却很少用到。另外 SVGALib中所包含的诸如键盘、 鼠标和游戏杆的接口也很少被其他应用程序所使用。

因此 S VG ALib的使用越来越少笔者也不建议用户使用这个图形库。当然如果用户的显示卡只支持标准VGA模式则SVGALib还是比较好的选择。

1.3 FrameBuffer

FrameBuffer是出现在2.2.xx内核当中的一种驱动程序接口。这种接口将显示设备抽象为帧缓冲区。用户可以将它看成是显示内存的一个映像将其映射到进程地址空间之后就可以直接进行读写操作而写操作可以立即反应在屏幕上。该驱动程序的设备文件一般是/dev/fb0、 /dev/fb 1等等。比如假设现在的显示模式是1024x768-8位色则可以通过如下的命令清空屏幕

$dd if=/dev/zero of=/dev/fb0 bs=1024 c ount=768

在应用程序中一般通过将FrameBuffer设备映射到进程地址空间的方式使用 比如下面的程序就打开/dev/fb0设备并通过mmap系统调用进行地址映射随后用mems et将屏

幕清空这里假设显示模式是1024x768-8位色模式线性内存模式int fb;unsigned char*fb_mem;fb=open(“/dev/fb0”,O_RDWR);fb_mem=mmap(NULL, 1024*768,PROT_READ|PROT_WRI T E,MAP_S HARED,fb,0);mems et (fb_mem,0, 1024*768);

FrameBuffer设备还提供了若干ioctl命令通过这些命令可以获得显示设备的一些固定信息比如显示内存大小、与显示模式相关的可变信息比如分辨率、象素结构、每扫描线的字节宽度 以及伪彩色模式下的调色板信息等等。

通过FrameBuffer设备还可以获得当前内核所支持的加速显示卡的类型通过固定信息得到这种类型通常是和特定显示芯片相关的。比如目前最新的内核2.4.9中就包含有对S 3、Matrox、 nVidia、 3Dfx等等流行显示芯片的加速支持。在获得了加速芯片类型之后应用程序就可以将PCI设备的内存I/Omemio映射到进程的地址空间。这些memio一般是用来控制显示卡的寄存器通过对这些寄存器的操作应用程序就可以控制特定显卡的加速功能。

PCI设备可以将自己的控制寄存器映射到物理内存空间而后对这些控制寄存器的访问给变成了对物理内存的访问。因此这些寄存器又被称为“memio”。一旦被映射到物理内存 Linux的普通进程就可以通过mm ap将这些内存I/O映射到进程地址空间这样就可以直接访问这些寄存器了。

当然因为不同的显示芯片具有不同的加速能力对memio的使用和定义也各自不同这时就需要针对加速芯片的不同类型来编写实现不同的加速功能。比如大多数芯片都提供了对矩形填充的硬件加速支持但不同的芯片实现方式不同这时就需要针对不同的芯片类型编写不同的用来完成填充矩形的函数。

说到这里读者可能已经意识到FrameBuffer只是一个提供显示内存和显示芯片寄存器从物理内存映射到进程地址空间中的设备。所以对于应用程序而言如果希望在FrameBuffer之上进行图形编程还需要完成其他许多工作。举个例子来讲 FrameBuffer就像一张画布使用什么样子的画笔如何画画还需要你自己动手完成。

1.4 LibGGI

Lib GGI试图建立一个一般性的图形接口而这个抽象接口连同相关的输入鼠标、键盘、游戏杆等抽象接口一起可以方便地运行在X Window、 SVGALib、 FrameBuffer等等之上。建立在Lib GGI之上的应用程序不经重新编译就可以在上述这些底层图形接口上运行。但不知何故 LibGGI的发展几乎停滞。

2 Linux图形领域的高级函数库

2.1 Xlib及其他相关函数库

在X Window系统中进行图形编程时可以选择直接使用Xlib。Xlib实际是对底层X协议的封装可通过该函数库进行一般的图形输出。如果你的X Server支持DGA则可以通过DGA扩展直接访问显示设备从而获得加速支持。对一般用户而言 由于Xlib的接口太原始而且复杂因此一般的图形程序选择其他高级一些的图形库作为基础。比如GT K、QT等等。这两个函数同时还是一些高级的图形用户界面支持函数库。由于种种原因GTK、QT等函数库存在有庞大、 占用系统资源多的问题不太适合在嵌入式系统中使用。这时你可以选择使用FLTK这是一个轻量级的图形函数库但它的主要功能集中在用户界面上提供了较为丰富的控件集。

2.2 SDL

SDL Simple DirectMedia Layer是一个跨平台的多媒体游戏支持库。其中包含了对图形、声音、游戏杆、线程等等的支持 目前可以运行在许多平台上其中包括X Window、XWindow with DGA、 Linux FrameBuffer控制台、 Linux S VGALib 以及Windows DirectX、BeOS等等。

因为SDL专门为游戏和多媒体应用而设计开发所以它对图形的支持非常优秀尤其是高级图形能力比如Alpha混和、透明处理、YUV覆盖、Gamma校正等等。而且在SDL环境中能够非常方便地加载支持OpenGL的Mes a库从而提供对二维和三维图形的支持。可以说 SDL是编写跨平台游戏和多媒体应用的最佳平台也的确得到了广泛应用。相关信息可参阅http://www.lib s d l.or g。

2.3 Allegro

Allegro是一个专门为x86平台设计的游戏图形库。最初的Allegro运行在DOS环境下而目前可运行在Linux FrameBuffe控制台、Linux S VGALib、X Window等系统上。Allegro提供了一些丰富的图形功能包括矩形填充和样条曲线生成等等而且具有较好的三维图形显示能力。 由于Allegro的许多关键代码是采用汇编编写的所以该函数库具有运行速度快、资源占用少的特点。然而 Allegro也存在如下缺点

1对线程的支持较差。 Allegro的许多函数是非线程安全的不能同时在两个以上的线程中使用。

2对硬件加速能力的支持不足在设计上没有为硬件加速提供接口。

有关Al legr o的进一步信息可参阅http://www.allegr o.c c/。

2.4 Mesa3D

Mes a3 D是一个兼容OpenGL规范的开放源码函数库是目前Linux上提供专业三维图形

支持的惟一选择。Mesa3D同时也是一个跨平台的函数库 能够运行在X Window、 XWindow with DGA、 BeOS、 Linux SVGALib等平台上。

有关Mes a3 D的进一步信息可参阅http://www.mes a3 d.org/。

2.5 DirectFB

DirectFB是专注于Linux FrameBuffer加速的一个图形库并试图建立一个兼容GTK的嵌入式GUI系统。它以可装载函数库的形势提供对加速FrameBuffer驱动程序的支持。 目前该函数库正在开发之中最新版本0.9.97详情可见http://www.dir e ct fb.or g/。3面向嵌入式Linux系统的图形用户界面

3.1 MicoroWindows/NanoX

MicroWindow s http://microwindow s.c ensoft.c om是一个开放源码的项目 目前由美国Century Software公司主持开发。该项目的开发一度非常活跃 国内也有人参与了其中的开发并编写了GB2312等字符集的支持。但在Qt/Embedded发布以来该项目变得不太活跃并长时间停留在0.89Pre7版本。可以说以开放源码形势发展的MicroWindows项目基本停滞。

Mic roWindow s是一个基于典型客户/服务器体系结构的GUI系统基本分为三层。最底层是面向图形输出和键盘、鼠标或触摸屏的驱动程序中间层提供底层硬件的抽象接口并进行窗口管理最高层分别提供兼容于X Window和Windows CE Win32子集的API。该项目的主要特色在于提供了类似X的客户/服务器体系结构并提供了相对完善的图形功能包括一些高级的功能 比如Alpha混合三维支持 TrueType字体支持等。但需要注意的是MicroWindow s的图形引擎存在许多问题可以归纳如下

1无任何硬件加速能力。

2图形引擎中存在许多低效算法 同时未经任何优化。 比如在直线或者圆弧绘图函数中存在低效的逐点判断剪切的问题。

3代码质量较差。 由于该项目缺少一个强有力的核心代码维护人员 因此代码质量参差不齐影响整体系统稳定性。这也是MicroWindows长时间停留在0.89Pre7版本上的原因。Mic roWindow s采用MPL条款发布该条款基本类似LGPL条款。

3.2 OpenGUI

Op enG UI http://w ww.tutok.s k/fas tg l/在Linux系统上存在已经很长时间了。最初的名字叫FastGL只支持256色的线性显存模式但目前也支持其他显示模式并且支持多种操作系统平台比如MS-D O S、QNX和Linux等等不过目前只支持x 86硬件平台。Op enGUI也分为三层。最低层是由汇编编写的快速图形引擎 中间层提供了图形绘制API包括线

条、矩形、圆弧等并且兼容于Borland的BGI API。第三层用C++编写提供了完整的GUI对象集。

OpenGUI采用LGPL条款发布。OpenGUI比较适合于基于x86平台的实时系统可移植性稍差 目前的发展也基本停滞。

3.3 Qt/Embedded

Qt/Embedded是著名的Qt库开发商TrollTec h http://www.trolltec h.c om/发布的面向嵌入式系统的Q t版本。因为Q t是KD E等项目使用的GUI支持库所以有许多基于Qt的X Window程序可以非常方便地移植到Qt/Embedded版本上。因此 自从Qt/Embedded以GPL条款形势发布以来就有大量的嵌入式L inux开发商转到了Qt/Embedded系统上。比如韩国的Mizi公司 台湾省的某些嵌入式Linux应用开发商等等。

不过在笔者看来 Qt/Embedded还有一些问题值得开发者注意

1 目前该系统采用两种条款发布其中包括GP L条款。对函数库使用GP L条款意味着其上的应用需要遵循GPL条款。当然了如果要开发商业程序 TrollTech也允许你采用另外一个授权条款这时就必须向TrollTech交纳授权费用了。

2 Qt/Embedded是一个C++函数库尽管Qt/Embedded声称可以裁剪到最少630 K但这时的Qt/Embedded库已经基本上失去了使用价值。低的程序效率、大的资源消耗也对运行Qt/Embedded的硬件提出了更高的要求。

3Qt/Embedded库目前主要针对手持式信息终端 因为对硬件加速支持的匮乏很难应用到对图形速度、功能和效率要求较高的嵌入式系统当中 比如机顶盒、游戏终端等等。

4Qt/Embedded提供的控件集风格沿用了PC风格并不太适合许多手持设备的操作要求。

5Qt/Embedded的结构过于复杂很难进行底层的扩充、定制和移植尤其是那个用来实现signal/s lot机制的著名的moc文件。

因为上述这些原因 目前所见到的 Qt/Embedded的运行环境 几乎是清一色基于StrongARM的iPAQ。

3.4 MiniGUI

Min iG UI http://w ww.minigu i.org是由笔者主持并由许多自由软件开发人员支持的一个自由软件项目 遵循LGP L条款发布其目标是为基于Linux的实时嵌入式系统提供一个轻量级的图形用户界面支持系统。该项目自 1998年底开始到现在 已历经3年多的开发过程。到目前为止 已经非常成熟和稳定。 目前我们已经正式发布了稳定版本1.0.9并且开始了新版本系列的开发 即MiniGUI Version 1.1.x该系列的正式版也即将发布。在MiniGUI几年的发展过程中有许多值得一提的技术创新点正是由于这些技术上的创新才使得Min iG UI更加适合实时嵌入式系统而且Min iG UI的灵活性非常好可以应用在包括手持设备、机顶盒、游戏终端等等在内的各种高端或者低端的嵌入式系统当中。这些技术创新包括

1 图形抽象层。 图形抽象层对顶层AP I基本没有影响但大大方便了Min iG UI应用程序的移植、调试等工作。 目前包含三个图形引擎 S VGAL ib、 L ib GGI 以及直接基于LinuxFrameBuffer的Native Engine利用LibGGI时可在X Window上运行MiniGUI应用程序并可非常方便地进行调试。与图形抽象层相关的还有输入事件的抽象层。Min iG UI现在已经被证明能够在基于ARM、MIP S、 StrongARM以及Pow erPC等的嵌入式系统上流畅运行。

2多字体和多字符集支持。这部分通过设备上下文 D C的逻辑字体LOGF ONT实现不管是字体类型还是字符集都可以非常方便地进行扩充。应用程序在启动时可切换系统字符集 比如GB、 BIG5、 EUC KR、 UJI S。利用DrawText等函数时可通过指定字体而获得其他字符集支持。对于一个窗口来说同时显示不同语种的文字是可能的。MiniGUI的这种字符集支持不同于传统通过UNICODE实现的多字符集支持这种实现更加适合于嵌入式系统。

3两个不同架构的版本。最初的MiniG UI运行在PThread库之上这个版本适合于功能单一的嵌入式系统但存在系统健壮性不够的缺点。在0.9.98版本中我们引入了MiniGUI-Lite版本这个版本在提高系统健壮性的同时通过一系列创新途径避免了传统C/S结构的弱点为功能复杂的嵌入式系统提供了一个高效、稳定的GUI系统。在MiniGUI 1.1.0版本的开发中我们参照SDL和Allegro的图形部分重新设计了图形抽象层并增强了图形功能 同时增强了MiniGUI-Lite版本的某些特性。这些特性包括

1MiniGUI-Lite支持层的概念。同一层可容纳多个能够同时显示的客户程序并平铺在屏幕上显示。

2新的GAL能够支持硬件加速能力并能够充分使用显示内存新GAL之上的新GDI接口得到进一步增强。新的GDI接口可以支持Alpha混和、透明位块传输、光栅操作、YUV覆盖、 Gamma校正 以及高级图形功能椭圆、多边形、样条曲线等等。Min iG UI新版本在图形方面的增强和提高将大大扩展它的应用领域希望能够对嵌入式Linux上的多媒体应用、游戏开发提供支持。

纵观嵌入式Linux系统上的各种图形系统方案我们发现许多图形系统如Qt/Emb e dde d和MicoroWindows只注重手持设备上的需求却不太注重其他应用领域的需求而其他许多需要图形支持的嵌入式Linux系统却需要许多独特的、高级的图形功能而不仅仅是图形用户界面。为此在接下来的开发中我们还将在如下领域继续开发MiniGUI

1提供运行在MiniG UI上的JAVA虚拟机AWT组件的实现。

2提供MiniGUI上的OpenGL实现。

3提供类QT控件集的C++封装。

3提供窗口/控件风格主题支持。

4在MiniGUI-Lite当中增加对矢量字体的支持。

4小结

综上所述笔者认为在嵌入式Linux图形领域还有许多有待开发人员仔细研究和解决的

问题。MiniGUI的新的发展也正源于对这些需求的认识之上。我们也衷心希望能够有更多的自由软件开发人员加盟MiniG UI的开发一同开发新的嵌入式Linux的图形系统。