一、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

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

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行

?