本文首先概述了Linux图形领域的基本设施,之后描述了一些可供嵌入式Linux系统使用的中级图形库以及图形用户界面支持系统。希望对嵌入式Linux系统的开发有所帮助。
1Linux图形领域的基础设施
本小节首先向读者描述Linux图形领域中常见的基础设施。之所以称为基础设施,是由于这种系统(或则函数库),通常作为其他中级图形或则图形应用程序的基本函数库。这种系统(或则函数库)包括:XWindow、SVGALib、FrameBuffer等等。
1.1XWindow
提起Linux上的图形,许多人首先想到的是XWindow。这一系统是目前类UNIX系统中处于控制地位的桌面图形系统。无疑,XWindow作为一个图形环境是成功的,它里面运行着包括CAD建模工具和办公套件在内的大量应用程序。但必须听到的是,因为XWindow在体系插口上的缘由,限制了其对游戏、多媒体的支持能力。用户在XWindow上运行VCD播放器,或则运行一些小型的三维游戏时,常常会发觉同样的硬件配置,却不能获得和Windows操作系统一样的图形疗效――即使使用了加速的XServer,其疗效也不能令人满意。另外,小型的应用程序(例如Mozilla浏览器)在XWindow上运行时的响应能力,也相当不能令人满意。其实,这儿有Linux内核在进程调度上的问题,也有XWindow的诱因。
XWindow为了满足对游戏、多媒体等应用对图形加速能力的要求,提供了DGA(直接图形访问)扩充,通过该扩充,应用程序可以在全屏模式下直接访问显示卡的帧缓冲区,并才能提供对个别加速功能的支持。
1.2SVGALib
SVGALib是Linux系统中最早出现的非X图形支持库。这个库从最初对标准VGA兼容芯片的支持开始,仍然发展到对旧式SVGA芯片的支持以及对当今流行的中级视频芯片的支持。它为用户提供了在控制台上进行图形编程的插口,使用户可以在PC兼容系统上便捷地获得图形支持。但该系统有如下不足:
1)插口零乱。SVGALib从最初的vgalib发展而至,保留了老系统的许多插口,而这种插口却不能良好地讨好新显示芯片的图形能力。
2)无法较好地隐藏硬件细节。许多操作,不能手动使用显示芯片的加速能力支持。
3)可移植性差。SVGALib目前只能运行在x86平台上,对其他平台的支持能力较差(Alpha平台除外)。
4)发展平缓,有被其他图形库替代的可能。SVGALib作为一个老的图形支持库,目前的应用范围越来越小,尤其在Linux内核降低了FrameBuffer驱动支持以后,有渐渐被其他图形库取代的征兆。
5)对应用的支持能力较差。SVAGLib作为一个图形库,对中级图形功能的支持,例如直线和曲线等等,却不能令人满意。虽然SVGALib有许多缺点,但SVGALib常常被其他图形库拿来初始化特定芯片的显示模式,并获得映射到进程地址空间的线性显示显存首地址(即帧缓冲区),而其他的插口却极少用到。另外linux系统图形界面,SVGALib中所包含的例如鼠标、鼠标和游戏杆的插口,也甚少被其他应用程序所使用。
为此,SVGALib的使用越来越少,笔者也不建议用户使用这个图形库。其实,假如用户的显示卡只支持标准VGA模式,则SVGALib还是比较好的选择。
1.3FrameBuffer
FrameBuffer是出现在2.2.xx内核当中的一种驱动程序插口。这些插口将显示设备具象为帧缓冲区。用户可以将它看成是显示显存的一个映像,将其映射到进程地址空间以后,就可以直接进行读写操作,而写操作可以立刻反应在屏幕上。该驱动程序的设备文件通常是/dev/fb0、/dev/fb1等等。例如,假定现今的显示模式是1024x768-8位色,则可以通过如下的命令清空屏幕:
$ dd if=/dev/zero of=/dev/fb0 bs=1024 count=768
在应用程序中,通常通过将FrameBuffer设备映射到进程地址空间的形式使用,例如下边的程序就打开/dev/fb0设备,并通过mmap系统调用进行地址映射,随即用memset将屏幕清空(这儿假定显示模式是1024x768-8位色模式,线性显存模式):
int fb;
unsigned char* fb_mem;
fb = open (“/dev/fb0”, O_RDWR);
fb_mem = mmap (NULL, 1024*768, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
memset (fb_mem, 0, 1024*768);
FrameBuffer设备还提供了若干ioctl命令,通过这种命令,可以获得显示设备的一些固定信息(例如显示显存大小)、与显示模式相关的可变信息(例如码率、象素结构、每扫描线的字节长度),以及伪彩色模式下的调色板信息等等。
通过FrameBuffer设备,还可以获得当前内核所支持的加速显示卡的类型(通过固定信息得到),这种类型一般是和特定显示芯片相关的。例如目前最新的内核(2.4.9)中,就包含有对S3、Matrox、nVidia、3Dfx等等流行显示芯片的加速支持。在获得了加速芯片类型以后,应用程序就可以将PCI设备的显存I/O(memio)映射到进程的地址空间。这种memio通常是拿来控制显示卡的寄存器,通过对这种寄存器的操作,应用程序就可以控制特定主板的加速功能。
PCI设备可以将自己的控制寄存器映射到化学显存空间,而后,对那些控制寄存器的访问,给弄成了对化学显存的访问。因而,这种寄存器又被称为“memio”。一旦被映射到化学显存,Linux的普通进程就可以通过mmap将这种显存I/O映射到进程地址空间,这样就可以直接访问那些寄存器了。[page]
其实,由于不同的显示芯片具有不同的加速能力,对memio的使用和定义也各自不同,这时,就须要针对加速芯片的不同类型来编撰实现不同的加速功能。例如大多数芯片都提供了对圆形填充的硬件加速支持,但不同的芯片实现方法不同,这时,就须要针对不同的芯片类型编撰不同的拿来完成填充圆形的函数。
说到这儿,读者可能早已意识到FrameBuffer只是一个提供显示显存和显示芯片寄存器从数学显存映射到进程地址空间中的设备。所以,对于应用程序而言,假若希望在FrameBuffer之上进行图形编程,还须要完成其他许多工作。举个反例来讲,FrameBuffer如同一张画布,使用哪些样子的笔触,怎么绘画,还须要你自己动手完成。
1.4LibGGI
LibGGI企图完善一个通常性的图形插口linux命令vi,而这个具象插口连同相关的输入(键盘、键盘、游戏杆等)具象插口一起,可以便捷地运行在XWindow、SVGALib、FrameBuffer等等之上。构建在LibGGI之上的应用程序,不经重新编译,就可以在上述那些底层图形插口上运行。但不知何故,LibGGI的发展几乎停滞。
2Linux图形领域的中级函数库
2.1Xlib及其他相关函数库
在XWindow系统中进行图形编程时,可以选择直接使用Xlib。Xlib实际是对底层X合同的封装,可通过该函数库进行通常的图形输出。假如你的XServer支持DGAlinux系统图形界面,则可以通过DGA扩充直接访问显示设备,因而获得加速支持。对通常用户而言,因为Xlib的插口太原始并且复杂,因而通常的图形程序选择其他中级一些的图形库作为基础。例如,GTK、QT等等。这两个函数同时还是一些中级的图形用户界面支持函数库。因为种种缘由,GTK、QT等函数库存在有庞大、占用系统资源多的问题,不太适宜在嵌入式系统中使用。这时,你可以选择使用FLTK,这是一个轻量级的图形函数库,但它的主要功能集中在用户界面上,提供了较为丰富的控件集。
2.2SDL
SDL(SimpleDirectMediaLayer)是一个跨平台的多媒体游戏支持库。其中包含了对图形、声音、游戏杆、线程等等的支持,目前可以运行在许多平台上,其中包括XWindow、XWindowwithDGA、LinuxFrameBuffer控制台、LinuxSVGALib,以及WindowsDirectX、BeOS等等。
由于SDL专门为游戏和多媒体应用而设计开发,所以它对图形的支持十分优秀,尤其是中级图形能力,例如Alpha混合、透明处理、YUV覆盖、Gamma校准等等。并且在SDL环境中才能十分便捷地加载支持OpenGL的Mesa库,进而提供对二维和三维图形的支持。
可以说,SDL是编撰跨平台游戏和多媒体应用的最佳平台,也的确得到了广泛应用。
2.3Allegro
Allegro是一个专门为x86平台设计的游戏图形库。最初的Allegro运行在DOS环境下,而目前可运行在LinuxFrameBuffe控制台、LinuxSVGALib、XWindow等系统上。Allegro提供了一些丰富的图形功能,包括圆形填充和样条曲线生成等等,并且具有较好的三维图形显示能力。因为Allegro的许多关键代码是采用汇编编撰的,所以该函数库具有运行速率快、资源占用少的特性。但是,Allegro也存在如下缺点:
1)对线程的支持较差。Allegro的许多函数是非线程安全的,不能同时在两个以上的线程中使用。
2)对硬件加速能力的支持不足,在设计上没有为硬件加速提供插口。
2.4Mesa3D
Mesa3D是一个兼容OpenGL规范的开放源码函数库,是目前Linux上提供专业三维图形支持的唯一选择。Mesa3D同时也是一个跨平台的函数库,才能运行在XWindow、XWindowwithDGA、BeOS、LinuxSVGALib等平台上。
2.5DirectFB
DirectFB是专注于LinuxFrameBuffer加速的一个图形库,并企图构建一个兼容GTK的嵌入式GUI系统。它以可装载函数库的形势提供对加速FrameBuffer驱动程序的支持。目前,该函数库正在开发之中(最新版本0.9.97),详情可见。
3面向嵌入式Linux系统的图形用户界面
3.1MicoroWindows/NanoX
MicroWindows(http://)是一个开放源码的项目,目前由法国CenturySoftware公司主持开发。该项目的开发一度十分活跃,国外也有人参与了其中的开发,并编撰了GB2312等字符集的支持。但在Qt/Embedded发布以来,该项目显得不太活跃,并长时间逗留在0.89Pre7版本。可以说,以开放源码形势发展的MicroWindows项目,基本停滞。
MicroWindows是一个基于典型顾客/服务器体系结构的GUI系统,基本分为三层。最底层是面向图形输出和鼠标、鼠标或触摸屏的驱动程序;中间层提供底层硬件的具象插口,并进行窗口管理;最高层分别提供兼容于XWindow和WindowsCE(Win32子集)的API。
该项目的主要特色在于提供了类似X的顾客/服务器体系结构,并提供了相对健全的图形功能,包括一些中级的功能,例如Alpha混和,三维支持,TrueType字体支持等。但须要注意的是,MicroWindows的图形引擎存在许多问题,可以归纳如下:
1)无任何硬件加速能力。
2)图形引擎中存在许多低效算法,同时未经任何优化。例如在直线或则弧形绘图函数中,存在低效的逐点判定剪切的问题。
3)代码质量较差。因为该项目缺乏一个强有力的核心代码维护人员,因而代码质量良莠不齐,影响整体系统稳定性。这也是MicroWindows长时间逗留在0.89Pre7版本上的缘由。
MicroWindows采用MPL条款发布(该条款基本类似LGPL条款)。
3.2OpenGUI
OpenGUI()在Linux系统上存在已然很长时间了。最初的名子叫FastGL,只支持256色的线性内存模式,但目前也支持其他显示模式,而且支持多种操作系统平台,例如MS-DOS、QNX和Linux等等,不过目前只支持x86硬件平台。OpenGUI也分为三层。最低层是由汇编编撰的快速图形引擎;中间层提供了图形勾画API,包括腰线、矩形、圆弧等,而且兼容于Borland的BGIAPI。第三层用C++编撰,提供了完整的GUI对象集。
OpenGUI采用LGPL条款发布。OpenGUI比较适宜于基于x86平台的实时系统,可移植性稍差,目前的发展也基本停滞。[page]
3.3Qt/Embedded
Qt/Embedded是知名的Qt库开发商TrollTech()发布的面向嵌入式系统的Qt版本。由于Qt是KDE等项目使用的GUI支持库,所以有许多基于Qt的XWindow程序可以十分便捷地移植到Qt/Embedded版本上。为此,自从Qt/Embedded以GPL条款形势发布以来,就有大量的嵌入式Linux开发商转入了Qt/Embedded系统上。诸如美国的Mizi公司,香港省的个别嵌入式Linux应用开发商等等。
不过,在笔者看来,Qt/Embedded还有一些问题值得开发者注意:
1)目前,该系统采用两种条款发布,其中包括GPL条款。对函数库使用GPL条款,意味着其上的应用须要遵守GPL条款。其实了,若果要开发商业程序,TrollTech也容许你采用另外一个授权条款,这时,就必须向TrollTech收取授权费用了。
2)Qt/Embedded是一个C++函数库,虽然Qt/Embedded宣称可以剪裁到最少630K,但这时的Qt/Embedded库早已基本上丧失了使用价值。低的程序效率、大的资源消耗也对运行Qt/Embedded的硬件提出了更高的要求。
3)Qt/Embedded库目前主要针对手持式信息终端,由于对硬件加速支持的短缺,很难应用到对图形速率、功能和效率要求较高的嵌入式系统当中,例如机顶盒、游戏终端等等。
4)Qt/Embedded提供的控件集风格沿袭了PC风格,并不太适宜许多手持设备的操作要求。
5)Qt/Embedded的结构过分复杂,很难进行底层的扩展、定制和移植,尤其是那种拿来实现signal/slot机制的知名的moc文件。
由于上述这种诱因,目前所看到的Qt/Embedded的运行环境,几乎是清一色基于StrongARM的iPAQ。
3.4MiniGUI
MiniGUI是由笔者主持,并由许多自由软件开发人员支持的一个自由软件项目(遵守LGPL条款发布),其目标是为基于Linux的实时嵌入式系统提供一个轻量级的图形用户界面支持系统。该项目自1998年末开始到现今,已历经3年多的开发过程。到目前为止,早已十分成熟和稳定。目前,我们早已即将发布了稳定版本1.0.9,而且开始了新版本系列的开发,即MiniGUIVersion1.1.x,该系列的即将版也正式发布。
在MiniGUI几年的发展过程中,有许多值得一提的技术创新点,正是因为这种技术上的创新,才促使MiniGUI愈发适宜实时嵌入式系统;并且MiniGUI的灵活性十分好,可以应用在包括手持设备、机顶盒、游戏终端等等在内的各类高档或则高端的嵌入式系统当中。这种技术创新包括:
1)图形具象层。图形具象层对顶楼API基本没有影响,但大大便捷了MiniGUI应用程序的移植、调试等工作。目前包含三个图形引擎,SVGALib、LibGGI以及直接基于LinuxFrameBuffer的NativeEngine,借助LibGGI时,可在XWindow上运行MiniGUI应用程序,并可十分便捷地进行调试。与图形具象层相关的还有输入风波的具象层。MiniGUI如今早已被证明才能在基于ARM、MIPS、StrongARM以及PowerPC等的嵌入式系统上流畅运行。
2)多字体和多字符集支持。这部份通过设备上下文(DC)的逻辑字体(LOGFONT)实现,不管是字体类型还是字符集,都可以十分便捷地进行扩展。应用程序在启动时,可切换系统字符集,例如GB、BIG5、EUCKR、UJIS。借助DrawText等函数时,可通过指定字体而获得其他字符集支持。对于一个窗口来说,同时显示不同语种的文字是可能的。MiniGUI的这些字符集支持不同于传统通过UNICODE实现的多字符集支持,这些实现愈发适宜于嵌入式系统。
3)两个不同构架的版本。最初的MiniGUI运行在PThread库之上红旗linux系统下载,这个版本适宜于功能单一的嵌入式系统,但存在系统强健性不够的缺点。在0.9.98版本中,我们引入了MiniGUI-Lite版本,这个版本在提升系统强健性的同时,通过一系列创新途径,防止了传统C/S结构的弱点,为功能复杂的嵌入式系统提供了一个高效、稳定的GUI系统。
在MiniGUI1.1.0版本的开发中,我们参照SDL和Allegro的图形部份,重新设计了图形具象层,并提高了图形功能,同时提高了MiniGUI-Lite版本的个别特点。这种特点包括:
1)MiniGUI-Lite支持层的概念。同一层可容纳多个才能同时显示的顾客程序,并平铺在屏幕上显示。
2)新的GAL才能支持硬件加速能力,并才能充分使用显示显存;新GAL之上的新GDI插口得到进一步提高。新的GDI插口可以支持Alpha混合、透明位块传输、光栅操作、YUV覆盖、Gamma校准,以及中级图形功能(椭圆、多边形、样条曲线)等等。
MiniGUI新版本在图形方面的提高和提升,将大大扩充它的应用领域,希望还能对嵌入式Linux上的多媒体应用、游戏开发提供支持。
综观嵌入式Linux系统上的各类图形系统方案,我们发觉,许多图形系统(如Qt/Embedded和MicoroWindows),只重视手持设备上的需求,却不太重视其他应用领域的需求,而其他许多须要图形支持的嵌入式Linux系统却须要许多奇特的、高级的图形功能,而不仅仅是图形用户界面。因此,在接出来的开发中,我们还将在如下领域继续开发MiniGUI:
1)提供运行在MiniGUI上的JAVA虚拟机AWT组件的实现。
2)提供MiniGUI上的OpenGL实现。
3)提供类QT控件集的C++封装。
3)提供窗口/控件风格主题支持。
4)在MiniGUI-Lite当中降低对矢量字体的支持。
4小结
综上所述,笔者觉得在嵌入式Linux图形领域,还有许多有待开发人员仔细研究和解决的问题。MiniGUI的新的发展,也正始于对这种需求的认识之上。我们也由衷希望还能有更多的自由软件开发人员加盟MiniGUI的开发,一齐开发新的嵌入式Linux的图形系统。
广州市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190
上海市东城区中关村东路18号B座15层1530室电话:(010)82350740邮编:100190