天天看點

framebuffer驅動全篇

在後續的幾篇裡面會詳細介紹如何編寫一個顯示卡的驅動程式。

framebuffer device

在核心裡面作為顯示卡驅動模型,許多函數和資料結構都是特定,正是這些特定的東西為我?

塹謀喑燙峁┝朔獎恪?

要開發frame buffer device驅動,你應該閱讀Source\Source\Documentation\fb

下面的說明檔案,三個重要檔案00-INDEX,framebuffer.txt,internals.txt

,其他檔案都是針對具體顯示卡晶片的說明了。

檔案00-INDEX譯文

文檔/documentation/fb的索引檔案。如果你對frame buffer裝置有什麼想法,mail:

Geert Uytterhoeven <[email protected]>

00-index 這個檔案

framebuffer.txt--- frame buffer 裝置介紹

internals.txt----frame buffer裝置内部快速浏覽

modedb.txt----關于視訊模式的資料

aty128fb.txt----關于ATI Rage128顯示卡的frame buffer裝置

clgenfb.txt-----關于Cirrus Logic的顯示卡

matroxfb.txt----關于Matrox的顯示卡

pvr2fb.txt----關于PowerVR 2的顯示卡

tgafb.txt----關于TGA(DECChip 21030)顯示卡

vesafb.txt----關于VESA顯示卡

幀緩沖裝置(framebuffer.txt譯文)

維護: Geert Uytterhoeven

最後校正:   May 10, 2001

翻譯:[email protected]

0.介紹

幀緩沖裝置提供了顯示卡的抽象描述。他同時代表了顯示卡上的顯存,應用程式通過定義好的?

湧诳梢苑夢氏鑰ǎ恍枰賴撞愕娜魏尾僮鳌?

該裝置使用特殊的裝置節點,通常位于/dev目錄,如/dev/fb*.

1.使用者角度的/dev/fb*

從使用者的角度看,幀緩沖裝置和其他位于/dev下面的裝置類似。他是一個字元裝置,通常

主裝置号是29,次裝置号定義幀緩沖的個數。

通常,使用如下方式(前面的數字代碼次裝置号)

        0 = /dev/fb0    First frame buffer

        1 = /dev/fb1    Second frame buffer

      ...

        31 = /dev/fb31  32nd frame buffer

考慮到向下相容,你可以建立符号連結:

      /dev/fb0current -> fb0

     /dev/fb1current -> fb1

and so on...

幀緩沖裝置也是一種普通的記憶體裝置,你可以讀寫其内容。例如,對螢幕抓屏:

  cp /dev/fb0 myfile

你也可以同時有多個顯示裝置,例如你的主機闆上出了内置的顯示卡還有另一獨立的

顯示卡。對應的幀緩沖裝置(/dev/fb0 and /dev/fb1 etc.)可以獨立工作。

應用程式如 X server一般使用/dev/fb0作為預設的顯示幀緩沖區。你可以自定

把某個裝置作為預設的幀緩沖裝置,設定$FRAMEBUFFER環境變量即可。在sh/bash:

    export FRAMEBUFFER=/dev/fb1

在csh中:

    setenv FRAMEBUFFER /dev/fb1

設定後,X server将使用第二個幀緩沖區裝置。

2.程式員角度看/dev/fb*

正如你所知,一個幀緩沖裝置和記憶體裝置類似/dev/mem,并且有許多共性。你可以

read,write,seek以及mmap()。不同僅僅是幀緩沖的記憶體不是所有的記憶體區,而是顯示卡

專用的那部分記憶體。

/dev/fb*也允許盡心ioctl操作,通過ioctl可以讀取或設定裝置參數。顔色映射表

也是通過Ioctl設定。檢視 就知道有多少ioctl應用以及相關資料結構。

這裡給出摘要:

  - 你可以擷取裝置一些不變的資訊,如裝置名,螢幕的組織(平面,象素,...)

對應記憶體區

    的長度和起始位址。

  -

也可以擷取能夠發生變化的資訊,例如位深,顔色格式,時序等。如果你改變這些值,

    驅動程式将對值進行優化,以滿足裝置特性(傳回EINVAL

,如果你的設定,裝置不支援)

  - 你也可以擷取或設定部分顔色表。

 所有這些特性讓應用程式十分容易的使用裝置。X server可以使用/dev/fb

*而不需知道硬體

 的寄存器是如何組織的。 XF68_FBDev是一個用于位映射(單色)X server

,唯一要做的就是

 在應用程式在相應的位置設定是否顯示。

 在新核心中,幀緩沖裝置可以工作于子產品中,允許動态加載。這類驅動必須調用

 register_framebuffer()在系統中注冊。使用子產品更友善!

3.幀緩沖分辨率設定

幀緩沖的分辨率可以用工具fbset設定。他可以改變視訊裝置的顯示模式。主要就是

改變目前視訊模式,如在啟動過程中,在/etc/rc.* 或 /etc/init.d

#define FB_MAJOR        29 

#define FB_MAX          32 

#define FBIOGET_VSCREENINFO 0x4600

#define FBIOPUT_VSCREENINFO 0x4601

#define FBIOGET_FSCREENINFO 0x4602

#define FBIOGETCMAP     0x4604

#define FBIOPUTCMAP     0x4605

#define FBIOPAN_DISPLAY     0x4606

#define FBIOGET_CON2FBMAP   0x460F

#define FBIOPUT_CON2FBMAP   0x4610

#define FBIOBLANK       0x4611     

#define FBIOGET_VBLANK      _IOR(‘F‘, 0x12, struct fb_vblank)

#define FBIO_ALLOC              0x4613

#define FBIO_FREE               0x4614

#define FBIOGET_GLYPH           0x4615

#define FBIOGET_HWCINFO         0x4616

#define FBIOPUT_MODEINFO        0x4617

#define FBIOGET_DISPINFO        0x4618

#define FB_TYPE_PACKED_PIXELS       0  

#define FB_TYPE_PLANES          1  

#define FB_TYPE_INTERLEAVED_PLANES  2  

#define FB_TYPE_TEXT            3  

#define FB_TYPE_VGA_PLANES      4  

#define FB_AUX_TEXT_MDA     0  

#define FB_AUX_TEXT_CGA     1  

#define FB_AUX_TEXT_S3_MMIO 2  

#define FB_AUX_TEXT_MGA_STEP16  3  

#define FB_AUX_TEXT_MGA_STEP8   4  

#define FB_AUX_VGA_PLANES_VGA4      0  

#define FB_AUX_VGA_PLANES_CFB4      1  

#define FB_AUX_VGA_PLANES_CFB8      2  

#define FB_VISUAL_MONO01        0  

#define FB_VISUAL_MONO10        1  

#define FB_VISUAL_TRUECOLOR     2  

#define FB_VISUAL_PSEUDOCOLOR       3  

#define FB_VISUAL_DIRECTCOLOR       4  

#define FB_VISUAL_STATIC_PSEUDOCOLOR    5  

#define FB_ACCEL_NONE       0  

#define FB_ACCEL_ATARIBLITT 1  

#define FB_ACCEL_AMIGABLITT 2  

#define FB_ACCEL_S3_TRIO64  3  

#define FB_ACCEL_NCR_77C32BLT   4  

#define FB_ACCEL_S3_VIRGE   5  

#define FB_ACCEL_ATI_MACH64GX   6  

#define FB_ACCEL_DEC_TGA    7  

#define FB_ACCEL_ATI_MACH64CT   8  

#define FB_ACCEL_ATI_MACH64VT   9  

#define FB_ACCEL_ATI_MACH64GT   10 

#define FB_ACCEL_SUN_CREATOR    11 

#define FB_ACCEL_SUN_CGSIX  12 

#define FB_ACCEL_SUN_LEO    13 

#define FB_ACCEL_IMS_TWINTURBO  14 

#define FB_ACCEL_3DLABS_PERMEDIA2 15   

#define FB_ACCEL_MATROX_MGA2064W 16

#define FB_ACCEL_MATROX_MGA1064SG 17   

#define FB_ACCEL_MATROX_MGA2164W 18

#define FB_ACCEL_MATROX_MGA2164W_AGP 19

#define FB_ACCEL_MATROX_MGAG100 20 

#define FB_ACCEL_MATROX_MGAG200 21 

#define FB_ACCEL_SUN_CG14   22 

#define FB_ACCEL_SUN_BWTWO  23 

#define FB_ACCEL_SUN_CGTHREE    24 

#define FB_ACCEL_SUN_TCX    25 

#define FB_ACCEL_MATROX_MGAG400 26 

#define FB_ACCEL_NV3        27 

#define FB_ACCEL_NV4        28 

#define FB_ACCEL_NV5        29 

#define FB_ACCEL_CT_6555x   30 

#define FB_ACCEL_3DFX_BANSHEE   31 

#define FB_ACCEL_ATI_RAGE128    32 

#define FB_ACCEL_IGS_CYBER2000  33 

#define FB_ACCEL_IGS_CYBER2010  34 

#define FB_ACCEL_IGS_CYBER5000  35 

#define FB_ACCEL_SIS_GLAMOUR    36 

#define FB_ACCEL_3DLABS_PERMEDIA3 37   

struct fb_fix_screeninfo {

    char id[16];        

    unsigned long smem_start;  

    __u32 smem_len;         

    __u32 type;         

    __u32 type_aux;         

    __u32 visual;       

    __u16 xpanstep;         

    __u16 ypanstep;         

    __u16 ywrapstep;    

    __u32 line_length;      

    unsigned long mmio_start;  

    __u32 mmio_len;         

    __u32 accel;          

    __u16 reserved[3];      

};

struct fb_bitfield {

    __u32 offset;       

    __u32 length;       

    __u32 msb_right;    

};

#define FB_NONSTD_HAM       1  

#define FB_ACTIVATE_NOW     0  

#define FB_ACTIVATE_NXTOPEN 1  

#define FB_ACTIVATE_TEST    2  

#define FB_ACTIVATE_MASK       15

#define FB_ACTIVATE_VBL        16  

#define FB_CHANGE_CMAP_VBL     32  

#define FB_ACTIVATE_ALL        64  

#define FB_ACCELF_TEXT      1  

#define FB_SYNC_HOR_HIGH_ACT    1  

#define FB_SYNC_VERT_HIGH_ACT   2  

#define FB_SYNC_EXT     4  

#define FB_SYNC_COMP_HIGH_ACT   8  

#define FB_SYNC_BROADCAST   16 

struct fb_cmap {

       __u32 start;                 

       __u32 len;                   

       __u16 *red;                 

       __u16 *green;              

       __u16 *blue;                

       __u16 *transp;                    

};

該結構在fb.h檔案中定義,在struct fb_ops結構中有兩個成員函數與其相關:

    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;                

在fpgen基礎操作下提供:

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);

在檔案中提供更多的cmap應用

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

點選在新視窗檢視原始圖檔

framebuffer驅動全篇(四)

本文介紹的裝置是位于/video目錄下面的anakinfb.c

驅動程式。雖然我不清楚那個裝置的特性,但是從對程式的分析中我們仍然知道如何編寫?

桓鰂rame buffer裝置驅動。

    本文是個标準的fb驅動。共221行,包含函數如下:

1.         static int  anakinfb_getcolreg(u_int regno, u_int *red, u_int *

green, u_int *blue, u_int *transp, struct fb_info *info) 31行

2.         static int anakinfb_setcolreg(u_int regno, u_int red, u_int green,

u_int blue,u_int transp, struct fb_info *info) 45行

3.         static int anakinfb_get_fix(struct fb_fix_screeninfo *fix, int con

, struct fb_info *info) 57行

4.         static int anakinfb_get_var(struct fb_var_screeninfo *var, int con

, struct fb_info *info) 75行

5.         static int anakinfb_set_var(struct fb_var_screeninfo *var, int con

, struct fb_info *info) 111行

6.         static int anakinfb_get_cmap(struct fb_cmap *cmap, int kspc, int

con,     struct fb_info *info) 117行

7.         static int anakinfb_set_cmap(struct fb_cmap *cmap, int kspc, int

con,     struct fb_info *info) 130行

8.         static int anakinfb_switch_con(int con, struct fb_info *info) 147行

9.         static int anakinfb_updatevar(int con, struct fb_info *info) 155行

10.     static void anakinfb_blank(int blank, struct fb_info *info) 161行

11.     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

中的函數可以工作的很好。這樣大家應該感到非常輕松了吧,隻要完成上述的幾個裝置相?

氐暮琭rame 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.         static int sti_encode_fix(struct fb_fix_screeninfo *fix, const

void *par, struct fb_info_gen *info) 60行

2.         static int sti_decode_var(const struct fb_var_screeninfo *var,void

*par, struct fb_info_gen *info) 71行

3.         static int sti_encode_var(struct fb_var_screeninfo *var, const

void *par, struct fb_info_gen *info) 78行

4.         static void sti_get_par(void *par, struct fb_info_gen *info) 94行

5.         static void sti_set_par(const void *par, struct fb_info_gen *info)

99行

6.         static int sti_getcolreg(unsigned regno, unsigned *red, unsigned *

green, unsigned *blue, unsigned *transp, struct fb_info *info) 104行

7.         static int sti_setcolreg(unsigned regno, unsigned red, unsigned

green, unsigned blue, unsigned transp, struct fb_info *info) 111行

8.         static void sti_set_disp(const void *par, struct display *disp,

struct fb_info_gen *info) 118行

9.         static void sti_detect(void) 127行

10.     static int sti_blank(int blank_mode, const struct fb_info *info) 132行

11.     int __init stifb_init(void) 161行

12.     void stifb_cleanup(struct fb_info *info) 201行

13.     int __init stifb_setup(char *options) 208行

其中1到10是必須的,參考下面的圖。

11是初始化代碼

12.13沒有完成具體功能

點選在新視窗檢視原始圖檔

再給出fb_fix_screeninfo系統調用結構圖:

點選在新視窗檢視原始圖檔

Frame buffer與console

Framebuffer作為顯示卡在核心中的注冊裝置,為了滿足應用需要,通常還要為console

操作提供專用操作函數。

Console是系統提供的一種特殊的文本輸出終端,如圖所示。常用的console

已經不再是從前的單色顯示,而是16

色或者更多顔色顯示。根據文本的代表的不同屬性,顯示不同的顔色。

把對console的支援内嵌到fb

的驅動中,或許有其自己的道理,我沒有看出來。不過既然要提供這種支援,我們的驅動?

縧蚓鴕碇右讀恕?

點選在新視窗檢視原始圖檔

在準fb裝置裝置驅動中是沒有對console支援的。

隻有在非标準的fb驅動,也就是基于skeletonfb.c架構的程式,需要提供這部分代碼。

下面從各個方面介紹framebuffer對console的支援。

1.       各個檔案中的支援

fb.h檔案中

struct fb_info結構中:

struct display *disp;             

    struct vc_data *display_fg;          

int (*changevar)(int);           

    int (*switch_con)(int, struct fb_info*);

fbgen.c檔案中:

void fbgen_set_disp(int con, struct fb_info_gen *info)

int fbgen_update_var(int con, struct fb_info *info)

int fbgen_switch(int con, struct fb_info *info)

新增加檔案fbcon.c

struct display fb_display[MAX_NR_CONSOLES];

char con2fb_map[MAX_NR_CONSOLES];

…..

新增加檔案fbcon.h:

struct display_switch

struct display

新增檔案console_struct.h:

struct vc_data

……

2.       console中的顔色設定

該部分内容準備略掉,可以自行參考fbcon-cfb*.c檔案。

3.       console和fb的高層了解

當我們在fb中引入console後,就相當于把一張白紙變成了一個日記本。本來對于fb

來說隻有顔色和位置的關系,引入console後,首先就是console的描述。

   每個console相當于日記本的一頁,不同的console可以切換。Console

因為是要顯示文本,又和字型聯系到一起。Console的管理是十分複雜的,遠遠超過了

framebuffer本身。在RH9中,我們可以自己體驗一下console和fb的協調問題。

使用Init3多使用者模式登陸,這裡是沒有X server支援的。所有的輸入輸出都是基于

console的。Framebuffer就相當于你的顯示器。通過ALT+CTRL+F

*,我們可以切換到不同的console,而每個console的設定都可以很獨立的完成。每隔

console會在自己的資料區記錄曆史指令,在不同的console

可以登陸不同的使用者到系統。但是,因為隻有一個螢幕,是以目前可視的console

隻有一個。Frame buffer驅動程式要能夠根據ALT+CTRL+F*切換指令去完成console

的切換顯示。

   這樣大家應該明白frame buffer和console的關系了吧。後續我們會具體講述fb對

console的支援。但是對console本身不會設計太多,具體參考tty或console

的設計。當完成了fb對console的支援,frame buffer device driver設計就完了:)

framebuffer驅動全篇(五)

Fb console中的字型

/driver/video目錄下:

font_6x11.c,font_8x8.c,font_8x16.c

font_acorn_8x8.c,font_pearl_8x8.c,

font_sun8x16.c,font_sun12x22.c

fonts.c

這些檔案都是用來處理在fbcon中的字型顯示問題。其中除最後一個檔案fonts.c

外,其他都是字模檔案由cpi2fnt産生。

/include/video/目錄下:

font.h

1.          首先介紹font.h檔案

font.h檔案中,定義了字型的描述結構

struct fbcon_font_desc {

    int idx;     /字型的索引号

    char *name;/字型的描述

    int width, height;/字模的寬和高

    void *data;/字模的起始指針

    int pref;    /額外資訊,平台用

};

width的值不一定是8的整數倍,考慮到計算機存儲的問題,即使width小于8

的整數倍,存儲時仍以位元組為機關,不足的右補齊0。

Linux核心自帶了7種字型,name依次為:

font_vga_8x8,

                            font_vga_8x16,

                            font_pearl_8x8,

                            font_vga_6x11,

                            font_sun_8x16,

                            font_sun_12x22,

                            font_acorn_8x8;

根據定義name長度不大于32位元組。

2.          Font.c檔案

 struct fbcon_font_desc *fbcon_find_font(char *name);

struct fbcon_font_desc *fbcon_get_default_font(int xres, int yres);

由此看來,linux中基于fbcon

的字型比較單一,描述和使用也相對簡單。主要是由于采用字模描述,隻描述256個ascii

字元,故存儲空間不大,從2048到11264不等。

Fbcon中的顔色查找表

Fbcon-cfbx表示該console使用的是xbpp顔色描述。顔色數為2^x。

在此,我們僅以x=8,x=24舉例,使用顔色分别是256色和真彩16M。

/driver/video/fbcon-cfb8.c

/driver/video/fbcon-cfb24.c

/include/video/fbcon-cfb8.h

/include/video/fbcon-cfb24.h

這4個檔案實作的具體的操作,而fbcon的底層操作,參考前面的fbcon

的介紹,不重複了:)

實作fbcon的顔色映射隻需完成下面的功能,以fb8為例:

struct display_switch fbcon_cfb8;  

void fbcon_cfb8_setup(struct display *p);

void fbcon_cfb8_bmove(struct display *p, int sy, int sx, int dy, int dx, int

height, int width);

void fbcon_cfb8_clear(struct vc_data *conp, struct display *p, int sy, int sx

, int height, int width);

void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int yy,

int xx);

void fbcon_cfb8_putcs(struct vc_data *conp, struct display *p, const unsigned

short *s, int count, int yy, int xx);

void fbcon_cfb8_revc(struct display *p, int xx, int yy);

void fbcon_cfb8_clear_margins(struct vc_data *conp, struct display *p,int

bottom_only);

fbcon_cfb8是系統的實作關鍵,具體解釋參考fbcon介紹。

fbcon_cfb8_setup函數完成設定display結構中next_line和next_palne的值。

fbcon_cfb8_bmove函數完成目前坐标的移動。

fbcon_cfb8_clear函數通過調用rectfill函數清螢幕緩沖區。

fbcon_cfb8_putc函數向螢幕輸出單字元,字型寬度必須小于等于16。

fbcon_cfb8_putcs函數向螢幕輸出字元串。

fbcon_cfb8_revc函數從螢幕輸入單個字元,并回顯到fb上。

fbcon_cfb8_clear_margins函數和fbcon_cfb8_clear類似,調用rectfill清除區域。

其中,fb_writel函數和fb_readl函數實作輸入輸出的底層操作。這兩個函數實際上實在

fbcon_h中定義的宏操作,IOMEM操作而已。

關注一下“(nibbletab_cfb8[*cdat++ >> 4] & eorx) ^ bgx,”

這是所謂8bpp的具體實作,不同的位深就在寫fb緩沖時展現了。讓我們從後向前分析,

1.()^bgx,顔色和背景色異或,隻有這樣才能保證背景色改變時,文字一直顯示。

2.~&eorx,eorx是前景色和背景色異或後的值,隻有在前景色和背景色一緻的時候,

eorx才是0。

3. nibbletab_cfb8[~],根據字型的~值,調用查找表,取顔色值

4.~從字型檔案中去讀字模的值。

還有點疑問,就是這兩句的作用,attr_fgcol在fbcon_h中定義:

fgx=attr_fgcol(p,c);

    bgx=attr_bgcol(p,c);

從前面的看,c應該是個字元的ascii碼,ascii與顔色有什麼關系呢?研究中….