Linux下的帧缓冲lcd应用编程及Framebuffer驱动程序模型
转自:http://www.cnblogs.com/shenhaocn/archive/2011/04/12/2013137.html
一、Linux的帧缓冲设备
帧 缓冲(framebuffer)是 Linux 为显示设备提供的一个接口,把显存抽象后的一种设备,他允许上层应用程序在图形模式下直接对显示缓冲区进行读写操作。这种操作是抽象的,统一的。用户不必 关心物理显存的位置、换页机制等等具体细节。这些都是由Framebuffer 设备驱动来完成的。帧缓冲驱动的应用广泛,在 linux 的桌面系统中,Xwindow 服务器就是利用帧缓冲进行窗口的绘制。尤其是通过帧缓冲可显示汉字点阵,成为 Linux汉化的唯一可行方案。
帧 缓冲设备对应的设备文件为/dev/fb*,如果系统有多个显示卡,Linux 下还可支持多个帧缓冲设备,最多可达 32 个,分别为/dev/fb0 到/dev/fb31,而/dev/fb 则为当前缺省的帧缓冲设备,通常指向/dev/fb0。当然在嵌入式系统中支持一个显示设备就够了。帧缓冲设备为标准字符设备,主设备号为29,次设备号 则从0到31。分别对应/dev/fb0-/dev/fb31。
通过/dev/fb,应用程序的操作主要有这几种:
1.读/写(read/write)/dev/fb:相当于读/写屏幕缓冲区。例如用 cp /dev/fb0 tmp 命令可将当前屏幕的内容拷贝到一个文件中,而命令 cp tmp > /dev/fb0 则将图形文件tmp直接显示在屏幕上。
2.映射(map)操作:由于 Linux 工作在保护模式,每个应用程序都有自己的虚拟地址空间,在应用程序中是不能直接访问物理缓冲区地址的。为此,Linux 在文件操作 file_operations 结构中提供了 mmap 函数,可将文件的内容映射到用户空间。对于帧缓冲设备,则可通过映射操作,可将屏幕缓冲区的物理地址映射到用户空间的一段虚拟地址中,之后用户就可以通过读写这段虚拟地址访问屏幕缓冲区,在屏幕上绘图了。
3.I/O控制:对于帧缓冲设备,对设备文件的 ioctl操作可读取/设置显示设备及屏幕的参数,如分辨率,显示颜色数,屏幕大小等等。ioctl 的操作是由底层的驱动程序来完成的。
在应用程序中,操作/dev/fb的一般步骤如下:
1.打开/dev/fb设备文件。
2.用 ioctl 操作取得当前显示屏幕的参数,如屏幕分辨率,每个像素点的比特数。根据屏幕参数可计算屏幕缓冲区的大小。
3.将屏幕缓冲区映射到用户空间(mmap)。
4.映射后就可以直接读写屏幕缓冲区,进行绘图和图片显示了。
典型程序段如下:
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
|
#include <linux/fb.h> int main() { int fbfd = 0; struct fb_var_screeninfo vinfo; struct fb_fix_screeninfo finfo; long int screensize = 0; /*打开设备文件*/ fbfd = open( "/dev/fb0" , O_RDWR); /*取得屏幕相关参数*/ ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo); ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo); /*计算屏幕缓冲区大小*/ screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8; /*映射屏幕缓冲区到用户地址空间*/ fbp=( char *)mmap(0,screensize,PROT_READ|PROT_WRITE,MAP_SHARED, fbfd, 0); /*下面可通过 fbp指针读写缓冲区*/ …… /*释放缓冲区,关闭设备*/ munmap(fbp, screensize); close(fbfd); } |
二、ioctl操作
ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)
获取fb_var_screeninfo结构的信息,在linux/include/linux/fb.h定义。
ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)
获取fb_fix_screeninfon结构的信息。在linux/include/linux/fb.h定义。
fbfd为设备文件号。
三.mmap函数
功能描述:
mmap函数是unix/linux下的系统调用
mmap将一个文件或者其它对象映射进内存。文件被映射到多个页上,如果文件的大小不是所有页的大小之和,最后一个页不被使用的空间将会清零。munmap执行相反的操作,删除特定地址区域的对象映射。
基于文件的映射,在mmap和munmap执行过程的任何时刻,被映射文件的st_atime可能被更新。如果st_atime字段在前述的情况下 没有得到更新,首次对映射区的第一个页索引时会更新该字段的值。用PROT_WRITE 和 MAP_SHARED标志建立起来的文件映射,其st_ctime 和 st_mtime
在对映射区写入之后,但在msync()通过MS_SYNC 和 MS_ASYNC两个标志调用之前会被更新。
用法:
1
2
3
4
5
6
7
|
#include <sys/mman.h> void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset); int munmap( void *start, size_t length); |
参数:
start:映射区的开始地址。
length:映射区的长度。
prot:期望的内存保护标志,不能与文件的打开模式冲突。是以下的某个值,可以通过or运算合理地组合在一起
PROT_EXEC //页内容可以被执行
PROT_READ //页内容可以被读取
PROT_WRITE //页可以被写入
PROT_NONE //页不可访问
flags:指定映射对象的类型,映射选项和映射页是否可以共享。它的值可以是一个或者多个以下位的组合体
MAP_FIXED //使用指定的映射起始地址,如果由start和len参数指定的内存区重叠于现存的映射空间,重叠部分将会被丢弃。如果指定的起始地址不可用,操作将会失败。并且起始地址必须落在页的边界上。
MAP_SHARED //与其它所有映射这个对象的进程共享映射空间。对共享区的写入,相当于输出到文件。直到msync()或者munmap()被调用,文件实际上不会被更新。
MAP_PRIVATE //建立一个写入时拷贝的私有映射。内存区域的写入不会影响到原文件。这个标志和以上标志是互斥的,只能使用其中一个。
MAP_DENYWRITE //这个标志被忽略。
MAP_EXECUTABLE //同上
MAP_NORESERVE //不要为这个映射保留交换空间。当交换空间被保留,对映射区修改的可能会得到保证。当交换空间不被保留,同时内存不足,对映射区的修改会引起段违例信号。
MAP_LOCKED //锁定映射区的页面,从而防止页面被交换出内存。
MAP_GROWSDOWN //用于堆栈,告诉内核VM系统,映射区可以向下扩展。
MAP_ANONYMOUS //匿名映射,映射区不与任何文件关联。
MAP_ANON //MAP_ANONYMOUS的别称,不再被使用。
MAP_FILE //兼容标志,被忽略。
MAP_32BIT //将映射区放在进程地址空间的低2GB,MAP_FIXED指定时会被忽略。当前这个标志只在x86-64平台上得到支持。
MAP_POPULATE //为文件映射通过预读的方式准备好页表。随后对映射区的访问不会被页违例阻塞。
MAP_NONBLOCK //仅和MAP_POPULATE一起使用时才有意义。不执行预读,只为已存在于内存中的页面建立页表入口。
fd:有效的文件描述词。如果MAP_ANONYMOUS被设定,为了兼容问题,其值应为-1。
offset:被映射对象内容的起点。
返回说明:
成功执行时,mmap()返回被映射区的指针,munmap()返回0。失败时,mmap()返回MAP_FAILED[其值为(void *)-1],munmap返回-1。errno被设为以下的某个值
EACCES:访问出错
EAGAIN:文件已被锁定,或者太多的内存已被锁定
EBADF:fd不是有效的文件描述词
EINVAL:一个或者多个参数无效
ENFILE:已达到系统对打开文件的限制
ENODEV:指定文件所在的文件系统不支持内存映射
ENOMEM:内存不足,或者进程已超出最大内存映射数量
EPERM:权能不足,操作不允许
ETXTBSY:已写的方式打开文件,同时指定MAP_DENYWRITE标志
SIGSEGV:试着向只读区写入
SIGBUS:试着访问不属于进程的内存区
四、编程实例:
内核:linux-2.6.29.1
目标板:友善之臂mini2440
arm-linux-gcc-4.3.2
==========================
Framebuffer驱动程序模型
下图会向你展示目前的framebuffer设备驱动的结构,最常用的是非标准驱动。很明显他所处的层次最高,程序编写是最容易的。理解了这个图的,你已经很轻松的去完成一个fb驱动,比如给sa1100,s2410,s2440系列的ARM的LCD控制器写驱动。
Color Map 剖析
在framebuffer驱动程序设计中,cmap这个东东太晕了。现在我要把他赤裸裸的剖析给大家:)
1. struct fb_cmap
1
2
3
4
5
6
7
8
9
|
/*颜色映射表*/ struct fb_cmap { __u32 start; /* First entry */ __u32 len; /* Number of entries */ __u16 *red; /* 红色 */ __u16 *green; /*绿色*/ __u16 *blue; /*蓝色*/ __u16 *transp; /* 透明度,允许 NULL */ }; |
该结构在fb.h文件中定义,在struct fb_ops结构中有两个成员函数与其相关:
1
2
3
4
|
/*获取颜色表*/ int (*fb_get_cmap)( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info); /*设定颜色表*/ int (*fb_set_cmap)( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info); |
在struct fb_info结构中有变量:
struct fb_cmap cmap; /* Current cmap */
在fpgen基础操作下提供:
1
2
3
4
5
6
7
8
|
extern int fbgen_get_cmap( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info); extern int fbgen_set_cmap( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info); |
在文件/* drivers/video/fbcmap.c */中提供更多的cmap应用
1
2
3
4
5
6
7
8
9
10
|
extern int fb_alloc_cmap( struct fb_cmap *cmap, int len, int transp); extern void fb_copy_cmap( struct fb_cmap *from, struct fb_cmap *to, int fsfromto); extern int fb_get_cmap( struct fb_cmap *cmap, int kspc, int (*getcolreg)(u_int, u_int *, u_int *, u_int *,u_int *, struct fb_info *), struct fb_info *fb_info); extern int fb_set_cmap( struct fb_cmap *cmap, int kspc, int (*setcolreg)(u_int, u_int, u_int, u_int, u_int, struct fb_info *), struct fb_info *fb_info); extern struct fb_cmap *fb_default_cmap( int len); extern void fb_invert_cmaps( void ); |
2. 通过文件解析
在anakinfb.c文件中,cmap如图
在stifb.c
本文介绍的设备是位于/video目录下面的anakinfb.c驱动程序。虽然我不清楚那个设备的特性,但是从对程序的分析中我们仍然知道如何编写一个frame buffer设备驱动。
本文是个标准的fb驱动。共221行,包含函数如下:
1
2
3
4
5
6
7
8
9
10
11
|
static int anakinfb_getcolreg(u_int regno, u_int *red, u_int *green, u_int *blue, u_int *transp, struct fb_info *info) 31行 static int anakinfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,u_int transp, struct fb_info *info) 45行 static int anakinfb_get_fix( struct fb_fix_screeninfo *fix, int con, struct fb_info *info) 57行 static int anakinfb_get_var( struct fb_var_screeninfo *var, int con, struct fb_info *info) 75行 static int anakinfb_set_var( struct fb_var_screeninfo *var, int con, struct fb_info *info) 111行 static int anakinfb_get_cmap( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info) 117行 static int anakinfb_set_cmap( struct fb_cmap *cmap, int kspc, int con, struct fb_info *info) 130行 static int anakinfb_switch_con( int con, struct fb_info *info) 147行 static int anakinfb_updatevar( int con, struct fb_info *info) 155行 static void anakinfb_blank( int blank, struct fb_info *info) 161行 int __init anakinfb_init( void ) 178行 |
函数1,2是寄存器操作用。函数3,4,5,6,7是fb_ops函数。函数8用于切换控制台。函数9用于更新变量。函数10用于闪烁屏幕。函数11用于初始化设备。
很奇怪,对fb设备的读写函数怎么没有!值得说明的是open,release,read,write,ioctl,mmap等函数的实现是由
fbmem.c文件实现了。也就是说所有的fb设备在给定了fb_info后,所有的操作都是一样的。在明确的fb_info前提下,fbmem.c中的
函数可以工作的很好。这样大家应该感到非常轻松了吧,只要完成上述的几个设备相关的函数,frame buffer设备的驱动就写完了:)
系统的结构如图:
Stifb驱动模型
linux/drivers/video/stifb.c - Generic frame buffer
driver for HP * workstations with STI (standard text interface) video
firmware.
这个驱动程序和前面的anakin设备完全不同,因为他不是采用标准的格式,而是根据 based on skeletonfb,
which wasCreated 28 Dec 1997 by Geert
Uytterhoeven也就是skeletonfb.c提供的框架完成的。
共230行,包含函数如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
static int sti_encode_fix( struct fb_fix_screeninfo *fix, const void *par, struct fb_info_gen *info) 60行 static int sti_decode_var( const struct fb_var_screeninfo *var, void *par, struct fb_info_gen *info) 71行 static int sti_encode_var( struct fb_var_screeninfo *var, const void *par, struct fb_info_gen *info) 78行 static void sti_get_par( void *par, struct fb_info_gen *info) 94行 static void sti_set_par( const void *par, struct fb_info_gen *info) 99行 static int sti_getcolreg(unsigned regno, unsigned *red, unsigned *green, unsigned *blue, unsigned *transp, struct fb_info *info) 104行 static int sti_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue, unsigned transp, struct fb_info *info) 111行 static void sti_set_disp( const void *par, struct display *disp, struct fb_info_gen *info) 118行 static void sti_detect( void ) 127行 static int sti_blank( int blank_mode, const struct fb_info *info) 132行 int __init stifb_init( void ) 161行 void stifb_cleanup( struct fb_info *info) 201行 int __init stifb_setup( char *options) 208行 |