全面的framebuffer详解二

转：http://blog.chinaunix.net/uid-28297667-id-3773729.html

（二）一个LCD显示芯片的驱动实例

以Skeleton LCD 控制器驱动为例，在LINUX中存有一个/fb/skeleton.c的skeleton的Framebuffer驱动程序，很简单，仅仅是填充了 fb_info结构，并且注册/注销自己。设备驱动是向用户程序提供系统调用接口，所以我们需要实现底层硬件操作并且定义file_operations 结构来向系统提供系统调用接口，从而实现更有效的LCD控制器驱动程序。

1）在系统内存中分配显存

在fbmem.c文件中可以看到, file_operations 结构中的open()和release()操作不需底层支持，但read()、write()和 mmap()操作需要函数fb_get_fix()的支持.因此需要重新实现函数fb_get_fix()。另外还需要在系统内存中分配显存空间，大多数的LCD控制器都没有自己的显存空间，被分配的地址空间的起始地址与长度将会被填充到fb_fix_screeninfo 结构的smem_start 和smem_len 的两个变量中.被分配的空间必须是物理连续的。

2）实现 fb_ops 中的函数

用户应用程序通过ioctl()系统调用操作硬件，fb_ops 中的函数就用于支持这些操作。（注： fb_ops结构与file_operations 结构不同，fb_ops是底层操作的抽象,而file_operations是提供给上层系统调用的接口，可以直接调用.

ioctl()系统调用在文件fbmem.c中实现，通过观察可以发现ioctl()命令与fb_ops’s 中函数的关系:

FBIOGET_VSCREENINFO fb_get_var

FBIOPUT_VSCREENINFO fb_set_var

FBIOGET_FSCREENINFO fb_get_fix

FBIOPUTCMAP fb_set_cmap

FBIOGETCMAP fb_get_cmap

FBIOPAN_DISPLAY fb_pan_display

如果我们定义了fb_XXX_XXX 方法，用户程序就可以使用FBIOXXXX宏的ioctl()操作来操作硬件。

文件linux/drivers/video/fbgen.c或者linux/drivers/video目录下的其它设备驱动是比较好的参考资料。在所有的这些函数中fb_set_var()是最重要的，它用于设定显示卡的模式和其它属性，下面是函数fb_set_var()的执行步骤：

1)检测是否必须设定模式

2)设定模式

3)设定颜色映射

4) 根据以前的设定重新设置LCD控制器的各寄存器。

第四步表明了底层操作到底放置在何处。在系统内存中分配显存后，显存的起始地址及长度将被设定到 LCD控制器的各寄存器中（一般通过fb_set_var() 函数），显存中的内容将自动被LCD控制器输出到屏幕上。另一方面，用户程序通过函数mmap()将显存映射到用户进程地址空间中，然后用户进程向映射空间发送的所有数据都将会被显示到LCD显示器上。

三、FrameBuffer的应用

（一）、一个使用FrameBuffer的例子

FrameBuffer主要是根据VESA标准的实现的，所以只能实现最简单的功能。

由于涉及内核的问题，FrameBuffer是不允许在系统起来后修改显示模式等一系列操作。（好象很多人都想要这样干，这是不被允许的，当然如果你自己写驱动的话，是可以实现的）.

对FrameBuffer的操作，会直接影响到本机的所有控制台的输出，包括XWIN的图形界面。

在struct fb_info 中的char fontname[40]; /* default font name */默认的字体

就可以实现显示的中文化－－－－难道 篮点linux就是这样搞得？？

好，现在可以让我们开始实现直接写屏：

1、打开一个FrameBuffer设备

2、通过mmap调用把显卡的物理内存空间映射到用户空间

3、直接写内存。

/********************************

File name : fbtools.h

*/

#ifndef _FBTOOLS_H_

#define _FBTOOLS_H_

#include <linux/fb.h>

//a framebuffer device structure;

typedef struct fbdev{

int fb;

unsigned long fb_mem_offset;

unsigned long fb_mem;

struct fb_fix_screeninfo fb_fix;

struct fb_var_screeninfo fb_var;

char dev[20];

} FBDEV, *PFBDEV;

//open & init a frame buffer

//to use this function,

//you must set FBDEV.dev="/dev/fb0"

//or "/dev/fbX"

//it's your frame buffer.

int fb_open(PFBDEV pFbdev);

//close a frame buffer

int fb_close(PFBDEV pFbdev);

//get display depth

int get_display_depth(PFBDEV pFbdev);

//full screen clear

void fb_memset(void *addr, int c, size_t len);

#endif

/******************

File name : fbtools.c

*/

#include <stdio.h>

#include <stdlib.h>

#include <fcntl.h>

#include <unistd.h>

#include <string.h>

#include <sys/ioctl.h>

#include <sys/mman.h>

#include <asm/page.h>

#include "fbtools.h"

#define TRUE        1

#define FALSE       0

#define MAX(x,y)        ((x)>(y)?(x)y))

#define MIN(x,y)        ((x)<(y)?(x)y))

//open & init a frame buffer

int fb_open(PFBDEV pFbdev)

{

pFbdev->fb = open(pFbdev->dev, O_RDWR);

if(pFbdev->fb < 0)

{

printf("Error opening %s: %m. Check kernel config\n", pFbdev->dev);

return FALSE;

}

if (-1 == ioctl(pFbdev->fb,FBIOGET_VSCREENINFO,&(pFbdev->fb_var)))

{

printf("ioctl FBIOGET_VSCREENINFO\n");

return FALSE;

}

if (-1 == ioctl(pFbdev->fb,FBIOGET_FSCREENINFO,&(pFbdev->fb_fix)))

{

printf("ioctl FBIOGET_FSCREENINFO\n");

return FALSE;

}

//map physics address to virtual address

pFbdev->fb_mem_offset = (unsigned long)(pFbdev->fb_fix.smem_start) & (~PAGE_MASK);

pFbdev->fb_mem = (unsigned long int)mmap(NULL, pFbdev->fb_fix.smem_len + pFbdev->fb_mem_offset,              PROT_READ | PROT_WRITE, MAP_SHARED, pFbdev->fb, 0);

if (-1L == (long) pFbdev->fb_mem)

{

printf("mmap error! mem:%d offset:%d\n", pFbdev->fb_mem, pFbdev->fb_mem_offset);

return FALSE;

}

return TRUE;

}

//close frame buffer

int fb_close(PFBDEV pFbdev)

{

close(pFbdev->fb);

pFbdev->fb=-1;

}

//get display depth

int get_display_depth(PFBDEV pFbdev);

{

if(pFbdev->fb<=0)

{

printf("fb device not open, open it first\n");

return FALSE;

}

return pFbdev->fb_var.bits_per_pixel;

}

//full screen clear

void fb_memset (void *addr, int c, size_t len)

{

memset(addr, c, len);

}

//use by test

#define DEBUG

#ifdef DEBUG

main()

{

FBDEV fbdev;

memset(&fbdev, 0, sizeof(FBDEV));

strcpy(fbdev.dev, "/dev/fb0");

if(fb_open(&fbdev)==FALSE)

{

printf("open frame buffer error\n");

return;

}

fb_memset(fbdev.fb_mem + fbdev.fb_mem_offset, 0, fbdev.fb_fix.smem_len);

fb_close(&fbdev);

}

（二）基于Linux核心的汉字显示的尝试

我们以一个简单的例子来说明字符显示的过程。我们假设是在虚拟终端1（/dev/tty1）下运行一个如下的简单程序。

main ( )

{

puts("hello, world.\n");

}

puts 函数向缺省输出文件(/dev/tty1)发出写的系统调用write(2)。系统调用到linux核心里面对应的核心函数是console.c中的 con_write()，con_write()最终会调用do_con_write( )。在do_con_write( )中负责把"hello, world.\n"这个字符串放到tty1对应的缓冲区中去。

do_con_write( )还负责处理控制字符和光标的位置。让我们来看一下do_con_write()这个函数的声明。

static int do_con_write(struct tty_struct * tty, int from_user, const unsigned char *buf, int count)

其中tty是指向tty_struct结构的指针，这个结构里面存放着关于这个tty的所有信息（请参照 linux/include/linux/tty.h）。Tty_struct结构中定义了通用（或高层）tty的属性（例如宽度和高度等）。在 do_con_write( )函数中用到了tty_struct结构中的driver_data变量。driver_data是一个vt_struct指针。在vt_struct结构中包含这个tty的序列号（我们正使用tty1，所以这个序号为1）。Vt_struct结构中有一个vc结构的数组vc_cons，这个数组就是各虚拟终端的私有数据。

static int do_con_write(struct tty_struct * tty, int from_user,const unsigned char *buf, int count)

{

struct vt_struct *vt = (struct vt_struct *)tty->driver_data;//我们用到了driver_data变量

. . . . .

currcons = vt->vc_num; file://我们在这里的vc_nums就是1

. . . . .

}

要访问虚拟终端的私有数据，需使用vc_cons〔currcons〕.d指针。这个指针指向的结构含有当前虚拟终端上光标的位置、缓冲区的起始地址、缓冲区大小等等。

"hello, world.\n"中的每一个字符都要经过conv_uni_to_pc( )这个函数转换成８位的显示字符。这要做的主要目的是使不同语言的国家能把１６位的UniCode码映射到8位的显示字符集上，目前还是主要针对欧洲国家的语言，映射结果为8位，不包含对双字节（double byte）的范围。

这种UNICODE到显示字符的映射关系可以由用户自行定义。在缺省的映射表上，会把中文的字符映射到其他的字符上，这是我们不希望看到也是不需要的。所以我们有两个选择∶

不进行conv_uni_to_pc( )的转换。

加载符合双字节处理的映射关系，即对非控制字符进行1对1的不变映射。我们自己定制的符合这种映射关系的UNICODE码表是direct.uni。要想查看/装载当前系统的unicode映射表，可使外部命令loadunimap。

经过conv_uni_to_pc( )转换之后，"hello, world.\n"中的字符被一个一个地填写到tty1的缓冲区中。然后do_con_write( )调用下层的驱动，把缓冲区中的内容输出到显示器上（也就相当于把缓冲区的内容拷贝到VGA显存中去）。

sw->con_putcs(vc_cons〔currcons〕.d, (u16 *)draw_from, (u16*)draw_to-(u16 *)draw_from, y, draw_x);

之所以要调用底层驱动，是因为存在不同的显示设备，其对应VGA显存的存取方式也不一样。

上面的Sw->con_putcs( )就会调用到fbcon.c中的fbcon_putcs()函数（con_putcs是一个函数的指针，在Framebuffer模式下指向 fbcon_putcs()函数）。也就是说在do_con_write( )函数中是直接调用了fbcon_putcs()函数来进行字符的绘制。比如说在256色模式下，真正负责输出的函数是void fbcon_cfb8_putcs(struct vc_data *conp, struct display *p,const unsigned short *s, int count, int yy, int xx)

显示中文

比如说我们试图输出一句中文∶putcs(你好\n );（你好的内码为0xc4,0xe3,0xba,0xc3）。这时候会怎么样呢，有一点可以肯定，＂你好＂肯定不会出现在屏幕上，国为核心中没有汉字字库，中文显示就是无米之炊了．

1 在负责字符显示的void fbcon_cfb8_putcs( )函数中，原有操作如下∶对于每个要显示的字符，依次从虚拟终端缓冲区中以WORD为单位读取（低位字节是ASCII码，高8位是字符的属性），由于汉字是双字节编码方式，所以这种操作是不可能显示出汉字的，只能显示出xxxx_putcs()是一个一个VGA字符．

要解决的问题∶

确保在do_con_write( )时uni_pc转换不会改变原有编码。一个很直接的实现方式就是加载一个我们自己定制的UNICODE映射表，loadunimapdirect.uni，或者直接把direct.uni置为核心的缺省映射表。

针对如上问题，我们要做的第一个尝试方案是如下。

首先需要在核心中加载汉字字库，然后修改fbcon_cfb8_putcs()函数，在 fbcon_cfb8_putcs( )中一次读两个WORD，检查这两个WORD的低位字节是否能拼成一个汉字，如果发现能拼成一个汉字，就算出这个汉字在汉字字库中的偏移，然后把它当成一个16 x 16的VGA字符来显示。

试验的结果表明∶

能够输出汉字，但仍有许多不理想的地方，比如说，输出以半个汉字开始的一串汉字，则这半个汉字后面的汉字都会是乱码。这是半个汉字的问题。

光标移动会破坏汉字的显示。表现为，光标移动过的汉字会变成乱码。这是因为光标的更新是通过xxxx_putc( )函数来完成的。

xxxx_putc( )函数与xxxx_putcs( )函数实现的功能类似，但是xxxx_putc()函数只刷新一个字符而不是一个字符串，因而xxxx_putc()的输入参数是一个整数，而不是一个字符串的地址。Xxxx_putc( )函数的声明如下∶void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int yy, int xx)

下一个尝试方案就是同时修改xxxx_putcs( )函数和xxxx_putc()函数。为了解决半个汉字的问题，每一次输出之前，都从屏幕当前行的起始位置开始扫描，以确定要输出的字符是否落在半个汉字的位置上。如果是半个汉字的位置，则进行相应的调整，即从向前移动一个字节的位置开始输出。

这个方案有一个困难，即xxxx_putc( )函数不用缓冲区的地址，而是用一个整数作为参数。所以xxxx_putc( )无法直接利用相邻的字符来判别该定符是否是汉字。

解决方案是，利用xxxx_putc( )的光标位置参数（yy, xx），可以逆推出该字符在缓冲区中的位置。但仍有一些小麻烦，在Linux的虚拟终端下，用户可能会上卷该屏幕（shift + pageup），导致光标的y座标和相应字符在缓冲区的行数不一致。相应的解决方案是，在逆推的过程中，考虑卷屏的参量。

这样一来，我们就又进了一步，得到了一个相对更好的版本。但仍有问题没有解决。敲入turbonetcfg，会发现菜单的边框字符也被当成汉字显示。这是因为，这种边框字符是扩展字符，也使用了字符的第8位，因而被当作汉字来显示。例如，单线一的制表符内码为0xC4，当连成一条长线就是由一连串0xC4 组成，而0xC4C4正 是汉字哪。于是水平的制表符被一连串的哪字替代了。要解决这个问题就非常不容易了，因为制表符的种类比较多，而且垂直制表符与其后面字符的组合型式又多种 多样，因而很难判断出相应位置的字符是不是制表符，从理论上说，无论采取什么样的排除算法，都必然存在误判的情况，因为总存在二义性，没有充足的条件来推 断出当前字符究竟是制表符还是汉字。

我们一方面寻找更好的排除组合算法，一方面试图寻找其它的解决方案。要想从根本上解决定个问题，必须利用其它的辅助信息，仅仅从缓冲区的字符来判断是不够的。

经过一番努力，我们发现，在UNIX中使用扩展字符时，都要先输出字符转义序列（Escape sequence）来切换当前字符集。字符转义序列是以控制字符Esc为首的控制命令，在UNIX的虚拟终端中完成终端控制命令，这种命令包括，移动光标座标、卷屏、删除、切换字符集等等。也就是说在输出代表制表符的字符串之前，通常是要先输出特定的字符转义序列。在console.c里，有根据字符转义序列命令来记录字符状态的变量。结合该变量提供的信息，就可以非常干净地把制表符与汉字区别开来。

在如上思路的指引下，我们又产生了新的解决方案。经过改动得到了另一各版本．

在这个新版本上，turbonetcfg在初次绘制的时候，制表符与汉字被清晰地区分开来，结果是非常正确的。但还有新的问题存在 ∶turbonetcfg 在重绘的时候（如切换虚拟终端或是移动鼠标光标的时候），制表符还是变成了汉字，因为重绘完全依赖于缓冲区，而这时用来记录字符集状态的变量并不反映当前字符集状态。问题还是没有最终解决。我们又回到了起点。∶( 看来问题的最终解决手段必须是把字符集的状态伴随每一个字符存在缓冲区中。让我们来研究一下缓冲区的结构。每一个字符占用16bit的缓冲区，低8位是 ASCII值，完全被利用，高8位包含前景颜色和背景颜色的属性，也没有多余的空间可以利用。因而只能另外开辟新的缓冲区。为了保持一致性，我们决定在原来的缓冲区后面添加相同大小的缓冲区，用来存放是否是汉字的信息。

也许有读者会问，我们只需要为每个字符添加一bit的信息来标志是否是汉字就足够了，为什么还要开辟与原缓冲区大小相同的双倍缓冲区，是不是太浪费呢？我们先放下这个问题，稍后再作回答。

其实，如果再添加一bit来标志是当前字符是汉字的左半边还是右半边的话，就会省去扫描屏幕上当前整行字符串的工作，这样一来，编程会更简单。但是有读者会问，即使是这样，使用8bit总够用了吧？为什么还要使用16bit呢？

我们的作法是∶用低8位来存放汉字另外一半的内码，用高8位中的2 bit来存放上面所讲的辅助信息，高8位的剩余6位可以用来存放汉字或其它编码方式（如BIG5或日文、韩文）的信息，从而使我们可以实现同屏显示多种双字节语言的字符而不会有相互干扰。另外，在编程时，双倍缓冲也比较容易计算。这样我们就回答了如上的两个问题。

迄今为止，我们有了一套彻底解决汉字和制表符相互干扰、半个汉字的刷新、重绘等问题的方案。剩下的就是具体编程实现的问题了。

但是，由于Framebuffer的驱动很多，修改每一个驱动的xxxx_putc()函数和xxxx_putcs( )函数会是一项不小的工作，而且，改动驱动程序后，每种驱动的测试也是很麻烦的，尤其是对于有硬件加速的显卡，修改和测试会更不容易。那么，存不存在一种不需要修改显卡驱动程序的方法呢？

经过努力，我们发现，可以在调用xxxx_putcs( )或xxxx_putc()函数输出汉字之前，修改vga字库的指针使其指向所需显示的汉字在汉字字库中的位置，即把一个汉字当成两个vga ASCII字符输出。也就是说，在内核中存在两个字库，一个是原有的vga字符字库，另一个是汉字字库，当我们需要输出汉字的时候，就把vga字库的指针指向汉字字库的相应位置，汉字输出完之后，再把该指针指向vga字库的原有位置。

这样一来，我们只需要修改fbcon.c和console.c，其中console.c负责维护双倍缓冲区，把每一个字符的信息存入附加的缓冲区；而 fbcon.c负责利用双倍缓冲区中附加的信息，调整vga字库的指针，调用底层的显示驱动程序。这里还有几个需要注意的地方∶

由于屏幕重绘等原因，调用底层驱动xxxx_putc( )和xxxx_putcs()的地方有多处。我们作了两个函数分别包装这两个调用，完成替换字库、调用xxxx_putcs( )或xxxx_putc( )、恢复字库等功能。

为了实现向上滚屏（shift + pageup）时也能看到汉字，我们需要作另外的修改。

Linux 在设计虚拟终端的时候，提供了回顾被卷出屏幕以外的信息的功能，这就是用热键来向上滚屏（shift + pageup）。当前被使用的虚拟终端拥有一个公共的缓冲区（soft back）， 用来存放被滚出屏幕以外的信息。当切换虚拟终端的时候，公共缓冲区的内容会被清除而被新的虚拟终端使用。向上滚屏的时候，显示的是公共缓冲区中的内容。因 此，如果我们想在向上滚屏的时候看到汉字，公共缓冲区也必须加倍，以确保没有信息丢失。当滚出屏幕的信息向公共缓冲区填写的时候，必须把相应的附加信息也 填写进公共缓冲区的附加区域。这就要求fbcon.c必须懂得利用公共缓冲区的附加信息。

当然，有另外一种偷懒的方法，那就是不允许用户向上滚屏，从而避免对公区缓冲区的处理。

把不同的编码方式（GB、BIG5、日文和韩文）写成不同的module，以实现动态加载，从而使得扩展新的编码方式不需要重新编译核心。

测试

本文实现的Kernel Patch文件（patch.kernel.chinese）可以从http://www.turbolinux.com.cn下载。Cd /usr/src/（该目录下应有Linux核心源程序所在的目录linux/） patch -p0 -b < patch.kernel.chinese make menuconfig 请选择Console drivers选项中的

〔*〕 Double Byte Character Display Support(EXPERIMENTAL)

〔*〕 Double Byte GB encode (module only)

〔*〕 VESA VGA graphics console

<*> Virtual Frame Buffer support (ONLY FOR TESTING!)

<*> 8 bpp packed pixels support

<*> 16 bpp packed pixels support

<*> VGA characters/attributes support

〔*〕 Select compiled-in fonts

〔*〕VGA 8x8 font

〔*〕VGA 8x16 font

make dep

make bzImage

make modules

make install

make modules_install

然后用新的核心启动。

Insmod encode-gb.o

四、其它

（一）   设置FrameBuffer

FrameBuffer，可以译作"帧缓冲"，有时简称为 fbdrv，基于fbdrv的console也被称之为fbcon。这是一种独立于硬件的抽象图形设备。FrameBuffer的优点在于其高度的可移植性、易使用性、稳定性。使用Linux内核的 FrameBuffer驱动（vesafb），可以轻松支持到1024X768X32bpp以上的分辩率。而且目前可得到的绝大多数linux版本所发行的内核中，已经预编译了FrameBuffer支持，通常不需要重新编译内核就可以使用。所以FrameBuffer也是zhcon推荐使用的驱动方式。

进入FrameBuffer可以简单地在系统启动时向kernel传送vga=mode-number的参数来激活FrameBuffer设备，如：

lilo:linux vga=305

将会启动1024x768x8bpp模式。

640x480    800x600    1024x768    1280x1024

8 bpp      769          771       773        775

16 bpp     785          788       791        794

32 bpp     786          789       792        795

（二）   要使linux缺省进入FrameBuffer，可以修改/etc/lilo.conf，加入一下语句：

vga=0x303

退出编辑，执行：

lilo -v

重新启动linux，可以使其进入800x600的256色模式。

grub也是一样，在grub.conf中的kernel行后面写上vga=xxx就行了，也可以用vga=ask，让系统启动的时候询问你用多大的分辨率

（三）我编译内核时，选择framebuffer模式，启动时屏幕上有一企鹅图片，不知这是如何造成的这个图片可以去掉或改动吗？

可以将drivers/video/fbcon.c: fbcon_setup()中if (logo) { } 代码去掉。