Linux系统常用的图形接口是FrameBuffer帧缓冲，实现了显存映射，生成了对应的/dev/fbX文件供用户操作，这需要内核打开相关选项。

本次实验在虚拟机上X86平台进行，可以为我们的第一次尝试去除交叉编译等不必要的麻烦，抓住主要矛盾。这里使用VirtualBox虚拟机，VirtualBox是目前个人感觉最好的虚拟机，比较简洁，不会给系统安装一大撮的服务；在上面安装了Red Hat Enterprise Linux AS4.0，使用AS4企业版，只因为一直使用的这个版本，感觉比较稳定，只安装基本的字符模式和开发包，差不多十分钟就能安装完成。

此时的系统只有字符界面，可以进行正常的编译、安装等开发工作，过会我们就要在上面实现基本的图形界面。

首先要确保内核打开了FrameBuffer支持选项，并且需要在系统启动参数中添加“vga=0×0314”，代表使用800*600分辨率，如果启动时能看到小企鹅图标，表明内核已经支持FrameBuffer，启动后查看是否有/dev/fb0等设备文件。

在这里首先说一下Linux系统编译安装源码包的注意事项，解开源码包有，首先查看README，看看基本功能介绍等，一般它会诉你如果要安装的话要查看哪个说明文件，一般都是INSTALL，在这个里面我们可以了解这个源码包依赖哪些包，以及编译安装方法，一般都是./configure、make、make install，当然要先安装它所依赖的源码包。

我以前一直不了解./configure里面的“–prefix”参数有什么大的用处，直接安装到默认路径不就行了吗，这也就给我的这次移植埋下了第一大隐患，在安装包的时候，系统中可能已经有一些早期版本，而早期版本一般都是安装在/usr目录下的，而我们的新版本，由于没有指定安装路径，一般都会安装到/usr/local下，导致版本冲突，调用的时候往往使用的还是老版本的可执行文件或库文件，所以安装一定要注意版本冲突问题。

因为Linux操作系统统一使用pkg-config工具来统一管理头文件路径和库路径，在新安装一个开发包后，会将一个开发包信息脚本放到pkg-config的目录下供其调用，而当系统中安装了不同版本的pkg-config，或者其它原因引起的，会同时存在两个pkg-config目录，一般都是/usr/lib/pkgconfig和/usr/local/lib/pkgconfig目录，而一般情况下系统只能搜寻前面的这个目录，所以有时候会导致，明明安装了那个开发包，却提示说pkg-config找不到，此时需要设置一个环境变量“export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig”就能解决，另外将“/usr/lib”和“/usr/local/lib”这两个路径加入到“/etc/ld.so.conf”并且执行“ldconfig”更新。

好了，如果在安装过程中出现开发包没安装，或库找不到的情况请对照以上两条解决。

首先进行编译安装DirectFB-1.4.1.tar.gz，没什么问题，顺利通过。编写以下测试程序并编译运行，如果能看到一条横线，那就成功了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#include <stdio.h>
#include <unistd.h>
#include <directfb.h>
 
static IDirectFB *dfb = NULL;
static IDirectFBSurface *primary = NULL;
 
static int screen_width  = 0;
static int screen_height = 0;
 
#define DFBCHECK(x...)                                         \
{                                                      	   \
    DFBResult err = x;                                         \
                                                               \
    if (err != DFB_OK)                                         \
    {                                                          \
        fprintf( stderr, "%s <%d>:\n\t", __FILE__, __LINE__ ); \
        DirectFBErrorFatal( #x, err );                         \
    }                                                          \
}
 
int main (int argc, char **argv)
{
	DFBSurfaceDescription dsc;
	DFBCHECK (DirectFBInit (&argc, &argv));
	DFBCHECK (DirectFBCreate (&dfb));
	DFBCHECK (dfb->SetCooperativeLevel (dfb, DFSCL_FULLSCREEN));
 
	dsc.flags = DSDESC_CAPS;
	dsc.caps  = DSCAPS_PRIMARY | DSCAPS_FLIPPING;
 
	DFBCHECK (dfb->CreateSurface( dfb, &dsc, &primary ));
	DFBCHECK (primary->GetSize (primary, &screen_width, &screen_height));
	DFBCHECK (primary->FillRectangle (primary, 0, 0, screen_width, screen_height));
 
	DFBCHECK (primary->SetColor (primary, 0x80, 0x80, 0xff, 0xff));
	DFBCHECK (primary->DrawLine (primary,
			                      0, screen_height / 2,
			       screen_width - 1, screen_height / 2));
 
	DFBCHECK (primary->Flip (primary, NULL, 0));
	sleep (5);
	primary->Release( primary );
	dfb->Release( dfb );
 
	return 23;
}

在进行GTK+环境安装的时候出了很多问题，包括开发包的依赖问题，库找不到，undefined symbol: FcDirCacheLoad，mandatory image surface backend feature could not be enabled，提示重新安装FreeType和FontConfig等问题请参考上文方法解决，因为经历过磨难，这里就直接将正确的包的安装顺利和配置参数给出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

pkg-config-0.23.tar.gz
./configure
make
make install
 
glib-2.20.4.tar.bz2 require pkg-config
./configure
make
make install
注：此包依赖新版本的pkg-config工具，因此在此之前对系统原有程序升级。
 
libpng-1.2.39.tar.bz2
./configure
make
make install
 
pixman-0.15.20.tar.gz
./configure
make
make install
 
freetype-2.3.9.tar.bz2
./configure
make
make install
 
fontconfig-2.7.1.tar.gz
./configure
make
make install
注：此包依赖FreeType，如果已经安装TreeType但还提示找不到，请根据前文修改。
 
cairo-1.8.8.tar.gz
./configure --enable-directfb=yes --enable-ft=yes --enable-ps=no --enable-svg=no
make
make install
注：此包依赖libpng pixman fontconfig，注意Enable DirectFB。
 
pango-1.24.5.tar.bz2
./configure
make
make install
注：依赖cairo glib
 
atk-1.27.90.tar.bz2
./configure --with-gtktarget-directfb --without-libtiff --without-libjpeg --without-libjasper
make
make install
注：注意GtkTarget DirectFB。

至此，开发包都已安装完毕，如果没有出错的话，那么我们就可以写一个GTK+代码进行测试，这里我写了一个最简单的窗体，包括一个按钮，单击按钮退出程序，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <gtk/gtk.h>
 
int main( int argc, char *argv[] )
{
	GtkWidget *window;
	GtkWidget *button;
 
	gtk_init(&argc, &argv);
 
	window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
	gtk_widget_set_size_request(GTK_WIDGET(window), 640, 480);
 
	button = gtk_button_new_with_label("Click Here");
 
	g_signal_connect(window,"destroy", G_CALLBACK(gtk_main_quit),NULL);
 
	g_signal_connect(button,"clicked", G_CALLBACK(gtk_main_quit),NULL);
 
 
	gtk_container_add(GTK_CONTAINER(window), GTK_WIDGET(button));
 
	gtk_widget_show_all(window);
 
	gtk_main();
 
	return(0);
}

一切正常的话就会出现如下图，能看到鼠标，但标题栏没有，样子也很难后，颜色也许可以通过RC文件修改，但是在我的虚拟机上显示出的整

个图像好你宽度都变成的1/2，前面的DirectFB测试也是如此。

GTK+ DirectFB Pic

因为开发板中目前使用的是Busybox自带的一个hwclock工具，可能精简过了，重新下载源码包编译了一个完整的hwclock，传到开发板运行，现象照旧，只是提示信息变了变。查看“/dev”目录下的确有rtc这个设备，用“ls -l”查看其设备号也都正常。

查看rtc的手册，没耐心看下去直接跳到最后，看到在“/usr/src/linux/Documentation”目录下有个“rtc.txt”文件（目录可能略有不同），里面有一段RTC的测试程序，拷出来编译后放到开发板上进行测试，还是有问题，再把测试程序中的其它部分都去除，只保留读写时间的测试项目，运行后发现读到的还是1970年的时间，不可写入。从测试代码中可以看到，在操作RTC的时候跟操作普通文件一样，首先打开设备文件“/dev/rtc”，再通过“ioctl”命令传入不同的参数（RTC_RD_TIME、RTC_UIE_ON、RTC_ALM_SET）进行操作。

至此，经过多次软件方面的测试，可以确定不是程序问题，那么就有可能是设备驱动或硬件问题。

由于重新编译过内核，不太确定编译选项，遂把开发板原始内核文件写进去，现象依旧。没办法看看开发板的硬件配置吧，看了开发板的手册，发现RTC不是使用MCU自带的时钟，而是使用了一个外扩的串行时钟芯片DS1339，它与MCU通过IIC总线进行通讯，到开发板上果然找到了该芯片，非常小，并且旁边还有一个时钟晶振，第一反应会不会是内核中没有把该驱动编进去呢。

打开内核配置选项，在RTC目录下找到了使用DS1339的配置选项，编进内核重新启动，在Log中出现了“rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0”，非常兴奋，总算有起色了，但是通往成功的道路往往并不是一帆风顺的。

重复了开头软件测试的过程，一如继往地无效，只有在“cat /proc/drivers/rtc”的时候有点反应，可以正常显示时间了，而且来到了新世纪2000年了，重启了几次，发现此处的时间是可以正常往前走的，感觉这边的时间显示的应该就是硬件时钟里的时间了，可为什么通过hwclock还是无法访问呢。

跑到“/dev”目录下找不到“rtc0”设备文件，明显与Log中关于“registered ds1339 as rtc0”冲突，手工建一个设备“rtc0”吧，主次设备号又不知道，乱建了几个都无效，而且还搞重启了。

后来才发现“/dev/rtc”对应内核中的GenRTC－－General RTC通用的RTC，就是为了应付某些命令产生的一个假的设备文件，并不能产生实际作用，读出来的时间也永远是1970年；可是我们的“rtc0”去哪了呢，跟踪了源码无解，不过有个意外发现：在注册RTC时会同时在三个地方创建文件，一个是“/proc/drivers/rtc”就是前面一直用的，用来反映设备状态的文件，该文件目前正常；一个是“/dev/rtc0”目前没有；最后一个是“/sys/class/rtc/rtc0”也没找到，“/sys”下整个就是空的。当然这三处与内核选项中也是有对应关系的，如果你在内核中没打开这三个相关选项，对应的文件也是不会创建的。

关于“/dev”与“/sys”是有一些历史原因的，前者是Linux 2.4内核使用的设备管理方式，由于固有的缺点到了Linux 2.6就不再使用了，改用“sysfs”虚拟文件系统来进行管理设备，但为什么我们的“/sys”目录下是空的呢，查看了“/etc/fstab”、“/etc/rc.d/init.d/filesystem”，原来在后者的初始化过程中只挂载了“/proc”，遂依照挂载了“sysfs”文件系统：“mount -n -t sysfs sysfs /sys”，此时在“/sys”目录已经能看到丰富的设备文件信息了，赶紧把这句话也加到启动脚本中吧。

“cat /sys/class/rtc/rtc0/dev”显示“254：0”这应该就是传说中的主、次设备号了吧，系统没有自动帮我们创建“/dev/rtc0”那自己手工建一个吧“mknod /dev/rtc0 c 254 0”，这回使用测试程序能读出时间了，用hwclock还是无效，完全正常，因为hwclock默认操作的是“/dev/rtc”，我们可以通过给hwclock命令增加参数指定设备文件，也可以把原来的“/dev/rtc”删除，建一个指向“/dev/rtc0”的链接“ln -s /dev/rtc0 /dev/rtc”。世界总于回复了平静，一切都按秩序正常的工作了，成就感又一次占领了至高点。

前面提到通过“/dev”管理设备有着固有的缺点，其中之一就是不能智能的创建设备文件，也可能出现设备文件与设备不对应的情况，在嵌入式开发中由于缺少其它服务脚本更有可能产生。