本文是 MiniGUI 体系结构系列文章的第四篇。图形抽象层（GAL）和输入抽象层（IAL）大大提高了 MiniGUI 的可移植性，并将底层图形设备和上层接口分离开来。这里将重点介绍 MiniGUI 的 GAL 和 IAL 接口，并以最新的 MiniGUI-Lite 版本为例，介绍基于 Linux FrameBuffer 的 Native 图形引擎的实现，以及特定嵌入式系统上输入引擎的实现。
在 MiniGUI 0.3.xx 的开发中，我们引入了图形和输入抽象层（Graphics and Input Abstract Layer，GAL 和 IAL）的概念。抽象层的概念类似 Linux 内核虚拟文件系统的概念。它定义了一组不依赖于任何特殊硬件的抽象接口，所有顶层的图形操作和输入处理都建立在抽象接口之上。而用于实现这一抽象接口的底层代码称为“图形引擎”或“输入引擎”，类似操作系统中的驱动程序。这实际是一种面向对象的程序结构。利用 GAL 和 IAL，MiniGUI 可以在许多已有的图形函数库上运行，比如 SVGALib 和 LibGGI。并且可以非常方便地将 MiniGUI 移植到其他 POSIX 系统上，只需要根据我们的抽象层接口实现新的图形引擎即可。比如，在基于 Linux 的系统上，我们可以在 Linux FrameBuffer 驱动程序的基础上建立通用的 MiniGUI 图形引擎。实际上，包含在 MiniGUI 1.0.00 版本中的私有图形引擎（Native Engine）就是建立在 FrameBuffer 之上的图形引擎。一般而言，基于 Linux 的嵌入式系统均会提供 FrameBuffer 支持，这样私有图形引擎可以运行在一般的 PC 上，也可以运行在特定的嵌入式系统上。
相比图形来讲，将 MiniGUI 的底层输入与上层相隔显得更为重要。在基于 Linux 的嵌入式系统中，图形引擎可以通过 FrameBuffer 而获得，而输入设备的处理却没有统一的接口。在 PC 上，我们通常使用键盘和鼠标，而在嵌入式系统上，可能只有触摸屏和为数不多的几个键。在这种情况下，提供一个抽象的输入层，就显得格外重要。
本文将介绍 MiniGUI 的 GAL 和 IAL 接口，并介绍私有图形引擎和特定嵌入式系统下的输入引擎实现。
 |
GAL 和 IAL 的结构是类似的，我们以 GAL 为例说明 MiniGUI GAL 和 IAL 抽象层的结构。
参见图 1。系统维护一个已注册图形引擎数组，保存每个图形引擎数据结构的指针。系统利用一个指针保存当前使用的图形引擎。一般而言，系统中至少有两个图形引擎，一个是“哑”图形引擎，不进行任何实际的图形输出；一个是实际要使用的图形引擎，比如 LibGGI 或者 SVGALib，或者 Native Engine。每个图形引擎的数据结构定义了该图形引擎的一些信息，比如标识符、属性等，更重要的是，它实现了 GAL 所定义的各个接口，包括初始化和终止、图形上下文管理、画点处理函数、画线处理函数、矩形框填充函数、调色板函数等等。
如果在某个实际项目中所使用的图形硬件比较特殊，现有的图形引擎均不支持。这时，我们就可以安照 GAL 所定义的接口实现自己的图形引擎，并指定 MiniGUI 使用这种私有的图形引擎即可。这种软件技术实际就是面向对象多态性的具体体现。
利用 GAL 和 IAL，大大提高了 MiniGUI 的可移植性，并且使得程序的开发和调试变得更加容易。我们可以在 X Window 上开发和调试自己的 MiniGUI 程序，通过重新编译就可以让 MiniGUI 应用程序运行在特殊的嵌入式硬件平台上。
在代码实现上，MiniGUI 通过 GFX 数据结构来表示图形引擎，见清单 1。
清单 1 MiniGUI 中的图形引擎结构（src/include/gal.h）55 typedef struct tagGFX |
系统启动之后，将根据配置寻找特定的图形引擎作为当前的图形引擎，并且对全局变量 cur_gfx 赋值。之后，当 MiniGUI 需要在屏幕上进行绘制之后，调用当前图形引擎的相应功能函数。比如，在画水平线时如下调用：
(*cur_gfx->drawhline) (gc, x, y, w, pixel); |
为方便程序书写，我们还定义了如下 C 语言宏：
167 #define PHYSICALGC (cur_gfx->phygc) |
这样，上述画线函数可以如下书写：
GAL_DrawVLine (gc, x, y, w, pixel); |
显然，只要在系统初始化时能够根据设定对 cur_gfx 进行适当的赋值，MiniGUI 就能够在相应的图形引擎之上进行绘制。
对底层图形引擎的调用，主要集中在 MiniGUI 的 GDI 函数中。比如，要绘制一条直线，MiniGUI 的 LineTo 函数定义如清单 2 所示：
255 void GUIAPI LineTo (HDC hdc, int x, int y) |
在 MiniGUI 的所有绘图函数中，要依次做如下几件事：
在上面的四个步骤当中，第 3 步和第 4 步实际可以放到底层引擎当中，从而能够大大提高 MiniGUI 的绘图效率。不过，这种性能上的提高，对块输出，比如填充矩形、输出位图来讲，并不是非常明显。在将来的底层图形引擎当中，我们将针对上述两点，进行较大的优化以提高图形输出效率。
如前所属，MiniGUI IAL 结构和 GAL 结构类似。在代码实现上，MiniGUI 通过 INPUT数据结构来表示输入引擎，见清单 3。
34 typedef struct tagINPUT |
系统启动之后，将根据配置寻找特定的输入引擎作为当前的输入引擎，并且对全局变量 cur_input 赋值。
(*cur_gfx->drawhline) (gc, x, y, w, pixel); |
为方便程序书写，我们还定义了如下 C 语言宏：
69 #define IAL_InitInput (*cur_input->init_input) |
在 src/kernel/event.c 中，我们如下调用底层的输入引擎，从而将输入引擎的数据转换为 MiniGUI 上层能够理解的消息（以 MiniGUI-Lite 为例），见清单 4：
172 #ifdef _LITE_VERSION |
从这段代码中可以看出，对定点设备来讲，比如鼠标或者触摸屏，MiniGUI 能够自动识别移动信息，也能够自动识别用户的单击和双击事件。这样，底层引擎只需提供位置信息和当前的按键状态信息就可以了。对类似键盘的东西，MiniGUI 也能够自动进行重复处理。当一个按键按下一段时间之后，MiniGUI 将连续发送该按键的消息给上层处理。对特定的嵌入式系统来讲，可以将某些按键映射为 PC 的某些键盘键，上层只需处理这些键盘键消息的按下和释放即可。这样，嵌入式系统上的某些键的功能就可以在 PC 上进行模拟了。
Native 图形引擎的图形驱动程序已经提供了基于Linux内核提供FrameBuffer之上的驱动，目前包括对线性 2 bpp、4bpp、8bpp和 16bpp 显示模式的支持。前面已经看到，GAL提供的接口函数大多数与图形相关，它们主要就是通过调用图形驱动程序来完成任务的。图形驱动程序屏蔽了底层驱动的细节，完成底层驱动相关的功能，而不是那么硬件相关的一些功能，如一些画圆，画线的GDI 函数。
下面基于已经实现的基于FrameBuffer 的驱动程序，讲一些实现上的细节。首先列出的核心数据结构 SCREENDEVICE。这里主要是为了讲解方便，所以删除了一些次要的变量或者函数。
|
上面PSD 是 SCREENDEVICE 的指针，GAL 是GAL 接口的数据结构。
我们知道，图形显示有个显示模式的概念，一个像素可以用一位比特表示，也可以用2，4，8，15，16，24，32个比特表示，另外，VGA16标准模式使用平面图形模式，而VESA2.0使用的是线性图形模式。所以即使是同样基于Framebuffer 的驱动，不同的模式也要使用不同的驱动函数：画一个1比特的单色点和画一个24位的真彩点显然是不一样的。
所以图形驱动程序使用了子驱动程序的概念来支持各种不同的显示模式，事实上，它们才是最终的功能函数。为了保持数据结构在层次上不至于很复杂，我们通过图形驱动程序的初始函数Open直接将子驱动程序的各功能函数赋到图形驱动程序的接口函数指针，从而初始化结束就使用一个简单的图形驱动接口。下面是子图形驱动程序接口（清单 6）。
typedef struct { |
可以看到，该接口中除了 Init 函数指针外，其他的函数指针都与图形驱动程序接口中的函数指针一样。这里的Init 函数主要用来完成图形驱动部分与显示模式相关的初始化任务。
下面介绍SCREENDEVICE数据结构，这样基本上就可以清楚图形引擎了。
一个SCREENDEVICE代表一个屏幕设备，它即可以对应物理屏幕设备，也可以对应一个内存屏幕设备，内存屏幕设备的存在主要是为了提高GDI 质量，比如我们先在内存生成一幅位图，再画到屏幕上，这样给用户的视觉效果就比较好。
首先介绍几个变量。
下面介绍各接口函数：
基本的初始化和终结函数。前面已经提到，在 Open 函数里要选择子图形驱动程序，将其实现的函数赋给本 PSD 结构的函数指针。这里我讲讲基于Frambebuffer 的图形引擎的初始化。
fb_open 首先打开Framebuffer的设备文件 /dev/fb0，然后利用 ioctl 读出当前Framebuffer的各种信息。填充到PSD 结构中。并且根据这些信息选出子驱动程序。程序当前支持fbvga16，fblin16，fblin8，即VGA16 标准模式，VESA线性16位模式，VESA线性8位模式。然后将当前终端模式置于图形模式。并保存当前的一些系统信息如调色板信息。最后，系统利用mmap 将 /dev/fb0 映射到内存地址。以后程序访问 /dev/fb0 就像访问一个数组一样简单。当然，这是对线性模式而言的，如果是平面模式，问题要复杂的多。光从代码来看，平面模式的代码是线性模式的实现的将近一倍。后面的难点分析里将讲解这个问题。
当使用8位或以下的图形模式时，要使用系统调色板。这里是调色板处理函数，它们和Windows API 中的概念类似，linux 系统利用 ioctl 提供了处理调色板的接口。
前面屡次提到内存屏幕的概念，内存屏幕是一个伪屏幕，在对屏幕图形操作过程中，比如移动窗口，我们先生成一个内存屏幕，将物理屏幕的一个区域拷贝到内存屏幕，再拷贝到物理屏幕的新位置，这样就减少了屏幕直接拷贝的延时。AllocateMemGC 用于给内存屏幕分配空间，MapMemGC 做一些初始化工作，而FreeMemGC 则释放内存屏幕。
这些是底层图形函数。分别是画点，读点，画水平线，画竖直线，画一个实心矩形。之所以在底层实现这么多函数，是为了提高效率。图形函数支持多种画图模式，常用的有直接设置，亦或，Alpha混合模式，从而可以支持各种图形效果。
Get* 函数用于从屏幕拷贝像素到一块内存区，而Put*函数用于将存放于内存区的像素画到屏幕上。PutBoxMask 与PutBox的唯一区别是要画的像素如果是白色，就不会被画到屏幕上，从而达到一种透明的效果。
从上面可以看到，这些函数的第一个参数是GAL类型而不是PSD类型，这是因为它们需要GAL层的信息以便在函数内部实现剪切功能。之所以不和其他函数一样在上层实现剪切，是因为这里的剪切比较特殊。比如PutBox,
在剪切输出域时，要同时剪切在缓冲中待输出的像素：超出剪切域的像素不应该被输出。所以，剪切已经不单纯是对线，矩形等GDI对象的剪切。对像素的剪切当然需要知道像素的格式，这些只是为底层所有，所以为了实现高效的剪切，我们选择在底层实现它们。这里所有的函数都有两个部分：先是剪切，再是读或者写像素。
Blit 用于在不同的屏幕设备(物理的或者内存的)之间拷贝一块像素点，CopyBox则用于在同一屏幕上实现区域像素的拷贝。如果使用的是线性模式，Blit的实现非常简单，直接memcpy 就可以了，而CopyBox 为了防止覆盖问题，必须根据不同的情况，采用不同的拷贝方式，比如从底到顶底拷贝，当新老位置在同一水平位置并且重复时，则需要利用缓冲间接拷贝。如果使用平面显示模式，这里就比较复杂了。因为内存设备总是采用线性模式的，所以就要判断是物理设备还是内存设备，再分别处理。这也大大地增加了fbvga16 实现的代码。
|
鼠标驱动程序非常简单，抽象意义上讲，初始化鼠标后，每次用户移动鼠标，就可以得到一个X 和 Y 方向上的位移值，驱动程序内部维护鼠标的当前位置，用户移动了鼠标后，当前位置被加上位移值，并通过上层Cursor支持，反映到屏幕上，用户就会认为鼠标被他正确地“移动”了。
事实上，鼠标驱动程序的实现是利用内核或者其他驱动程序提供的接口来完成任务的。Linux 内核驱动程序使用设备文件对大多数硬件进行了抽象，比如，我们眼中的 ps/2 鼠标就是 /dev/psaux， 鼠标驱动程序接口如清单 7 所示。
typedef struct _mousedevice { |
现在有各种各样的鼠标，例如ms 鼠标， ps/2 鼠标，总线鼠标，gpm 鼠标，它们的主要差别在于初始化和数据包格式上。
例如，打开一个GPM 鼠标非常简单，只要将设备文件打开就可以了，当前终端被切换到图形模式时，GPM 服务程序就会把鼠标所有的位移信息放到设备文件中去。
static int GPM_Open(void) |
对于PS/2 鼠标，不但要打开它的设备文件，还要往该设备文件写入控制字符以使得鼠标能够开始工作。
static int PS2_Open(void) |
各鼠标的数据包格式是不一样的。而且在读这些数据时，首先要根据内核驱动程序提供的格式读数据，还要注意同步：每次扫描到一个头，才能读后面相应的数据，象Microwindows由于没有同步，在某些情况下，鼠标就会不听“指挥”。
鼠标驱动程序中，还有一个“加速”的概念。程序内部用两个变量：scale 和thresh 来表示。当鼠标的位移超过 thresh 时，就会被放大 scale 倍。这样，最后的位移就是：
dx = thresh + (dx - thresh) * scale; |
至此，mouse driver 基本上很清楚了，上面的接口函数中GetButtonInfo用来告诉调用者该鼠标支持那些button， suspend 和resume 函数是用来支持虚屏切换的，下面的键盘驱动程序也一样。
在实现键盘驱动程序中遇到的第一个问题就是使用设备文件 /dev/tty还是 /dev/tty0。
# echo 1 > /dev/tty0 |
结果都将把1 输入到当前终端上。另外，如果从伪终端上运行它们，则第一条指令会将 1 输出到控制台的当前终端，而第二条指令会把 1 输出到当前伪终端上。从而 tty0 表示当前控制台终端，tty 表示当前终端（实际是当前进程控制终端的别名而已）。
tty0 的设备号是 4，0
tty1 的设备号是 5， 0
/dev/tty 是和进程的每一个终端联系起来的，/dev/tty 的驱动程序所做的只是把所有的请求送到合适的终端。
缺省情况下，/dev/tty 是普通用户可读写的，而/dev/tty0 则只有超级用户能够读写，主要是基于这个原因，我们目前使用 /dev/tty 作为设备文件。后面所有有关终端处理的程序的都采用它作为当前终端文件，这样也可以和传统的 Unix 相兼容。
键盘驱动程序接口如清单 8 所示。
typedef struct _kbddevice { |
基本原理非常简单，初始化时打开 /dev/tty，以后就从该文件读出所有的数据。由于MiniGUI 需要捕获 KEY_DOWN 和 KEY_UP 消息，键盘被置于原始(raw)模式。这样，程序从 /dev/tty 中直接读出键盘的扫描码，比如用户按下A 键，就可以读到158，放下，又读到30。原始模式下，程序必须自己记下各键的状态，特别是shift，ctrl，alt，caps lock 等，所以程序维护一个数组，记录了所有键盘的状态。
这里说明一下鼠标移动，按键等事件是如何被传送到上层消息队列的。MiniGUI工作在用户态，所以它不可能利用中断这种高效的机制。没有内核驱动程序的支持，它也很难利用信号等Unix系统的IPC机制。MiniGUI可以做到的就是看 /dev/tty， /dev/mouse 等文件是否有数据可以读。上层通过不断调用 GAL_WaitEvent 尝试读取这些文件。这也是线程Parser的主要任务。GAL_WaitEvent 主要利用了系统调用select 这一类Unix系统中地位仅次于ioctl的系统调用完成该功能。并将等待到的事件作为返回值返回。
至此介绍了键盘和鼠标的驱动程序，作为简单的输入设备，它们的驱动是非常简单的。事实上，它们的实现代码也比较少，就是在嵌入式系统中要使用的触摸屏，如果操作系统内核支持，其驱动程序也是非常简单的：它只不过是一种特殊的鼠标。
|
如前所述，基于 Linux 的嵌入式系统，其内核一般具备对 FrameBuffer 的支持，从而可以利用已有的 Native 图形引擎。在 MiniGUI 代码中，可通过调整 src/gal/native/native.h 中的宏定义而定义函数库中是否包含特定的图形引擎驱动程序（清单 9）：
16 /* define or undefine these macros |
其中，HAVETEXTMODE 定义系统是否有文本模式，可将 MiniGUI 中用来关闭文本模式的代码屏蔽掉。_FBLIN_2_SUPPORT 和_FBLIN2_SUPPORT 分别用来定义 big endian 和 little endian 的 2bpp 驱动程序。
对于输入引擎来说，情况就有些不同了。因为目前还没有统一的处理输出设备的接口，而且每个嵌入式系统的输入设备也各不相同，所以，我们通常要针对特定嵌入式系统重新输入引擎。下面的代码就是针对 ADS 基于 StrongARM 的嵌入式开发系统编写的输入引擎（清单 10）：
30 在上述输入引擎中，完全忽略了键盘相关的函数实现，代码集中在对触摸屏的处理上。显然，输入引擎的编写并不是非常困难的。 本文详细介绍了 MiniGUI 的 GAL 和 IAL 接口，并以 Native 图形引擎和输入引擎为例，介绍了具体图形引擎和输入引擎的实现。当然，MiniGUI 目前的 GAL 和 IAL 接口还有许多不足之处，比如和上层的 GDI 耦合程度不高，从而对效率有些损失。在 MiniGUI 将来的开发中，我们将重新设计 GDI 以及底层的图形引擎接口，以便针对窗口系统 |
/3 
文章评论（0条评论）
登录后参与讨论