FrameBuffer的理解（转）

大家都知道Unix/Linux系統是由命令驅動的。那麼最基本的系統是命令行的（就是想DOS一樣的界面）。X－Window－System 是Unix/Linux上的圖形系統，它是通過X－Server來控制硬件的。但有一些Linux的發行版在引導的時候就會在屏幕上出現圖形，這時的圖形 是不可能由X來完成的，那是什麼機制呢？答案是FrameBuffer。
FrameBuffer不是一個圖形系統，更不是窗口系統。它比X要低級，簡單來說FrameBuffer就是一種機制的實現。這種機制是把屏幕上的每個 點映射成一段線性內存空間，程序可以簡單的改變這段內存的值來改變屏幕上某一點的顏色。X的高度可移植性就是來自於這種機制，不管是在那種圖形環境下，只 要有這種機制的實現就可以運行X。所以在幾乎所有的平台上都有相應的X版本的移植。
好了，閒話少說，下面我們來看看可以利用FrameBuffer來幹點什麼。首先看看你是否有了相應的驅動：找一下在/dev/下是否有fb*這個設備文件，這是個字符類的特殊文件。

ls -l /dev/fb0 (Enter)
crw-rw---- 1 root video 29, 0 Jan 27 15:32 /dev/fb0

如果沒有這個文件也可以找找其他的比如：/dev/fb1,/dev/fb2...如果找不到這些文件，那就得重新編譯內核了。下面假設存在這個文件/dev/fb0，這就是FrameBuffer的設備文件。
有了這個我們可以play with FrameBuffer了。（一下的操作不一定要在X下，可以在啟動了FrameBuffer的虛擬控制台下）

cat /dev/fb0 > sreensnap

ls -l sreensnap

-rw-r--r-- 1 wsw wsw 6291456 Jan 27 21:30 sreensnap

我們得到了一個恰好6M的文件，再做下面的操作：

clear /*清楚屏幕的輸出*/
cat sreensnap > /dev/fb0
是不是奇怪的事情發生了？好像是中了病毒一般？屏幕又恢復了以前的狀態？不用著急，

clear

這樣屏幕就正常了。

通過以上的操作，我想你也猜到了。文件/dev/fb0就是控制屏幕上的每一點的顏色的文件。我們可以寫程序來改變這個文件的內容，就可以方便的在屏幕上畫圖了:-)

我下面就來寫一個小程序，探測一下屏幕的屬性。


#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>

int main () {
int fp=0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;
fp = open ("/dev/fb0",O_RDWR);

if (fp < 0){
printf("Error : Can not open framebuffer device/n");
exit(1);
}

if (ioctl(fp,FBIOGET_FSCREENINFO,&finfo)){
printf("Error reading fixed information/n");
exit(2);
}

if (ioctl(fp,FBIOGET_VSCREENINFO,&vinfo)){
printf("Error reading variable information/n");
exit(3);
}

printf("The mem is :%d/n",finfo.smem_len);
printf("The line_length is :%d/n",finfo.line_length);
printf("The xres is :%d/n",vinfo.xres);
printf("The yres is :%d/n",vinfo.yres);
printf("bits_per_pixel is :%d/n",vinfo.bits_per_pixel);
close (fp);
}

struct fb_var_screeninfo 和 struct fb_fix_screeninfo 兩個數據結構是在/usr/include/linux/fb.h中定義的，裡面有些有趣的值：（都是無符號32位的整數）
在fb_fix_screeninfo中有
__u32 smem_len 是這個/dev/fb0的大小，也就是內存大小。
__u32 line_length 是屏幕上一行的點在內存中佔有的空間，不是一行上的點數。
在fb_var_screeninfo 中有
__u32 xres ，__u32 yres 是x和y方向的分辨率，就是兩個方向上的點數。
__u32 bits_per_pixel 是每一點佔有的內存空間。

把上面的程序編譯以後運行，在我的機器上的結果如下：
The mem is :6291456
The line_length is :4096
The xres is :1024
The yres is :768
bits_per_pixel is :32

內存長度恰好是6M，每行佔有4M的空間，分辨率是1024x768，色彩深度是32位。細心的你可能已經發現有些不對。屏幕上的點有 1024x768＝786432個，每個點佔有32比特。屏幕一共的佔有內存數為32x786432＝25165824 就是3145728字節，恰好是3M但是上面的程序告訴我們有6M的存儲空間。這是因為在現代的圖形系統中大多有緩衝技術，顯存中存有兩頁屏幕數據，這是 方便快速的改變屏幕內容實現動畫之類比較高的要求。關於這種緩衝技術有點複雜，我們目前先不討論。對於我們來說只有這3M內存來存放這一個屏幕的顏色數 據。
好了，現在你應該對FrameBuffer有一個大概的瞭解了吧。那麼接下來你一定會想在屏幕上畫一些東西，讓我們先從畫一個點開始吧。先說說我的想法： 在類Unix系統中，一切東西都是文件。我們對屏幕的讀寫就可以轉換成對/dev/fb0的讀寫。那麼就把/dev/fb0用open打開，再用 lseek定位要讀寫的位置，最後調用read或者write來操作。通過這麼一大段的操作我們才完成了對一個點的讀或者寫。這種方法開銷太大了。還有一 種方法，我們把/dev/fb0映射到程序進程的內存空間中來，然後得到一個指向這段存儲空間的指針，這樣就可以方便的讀寫了。但是我們要知道能映射多少 和該映射多少，這能很方便的從上面一個程序得出的參數來決定。
下面是程序代碼：

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>

int main () {
int fp=0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;
long screensize=0;
char *fbp = 0;
int x = 0, y = 0;
long location = 0;
fp = open ("/dev/fb0",O_RDWR);

if (fp < 0){
printf("Error : Can not open framebuffer device/n");
exit(1);
}

if (ioctl(fp,FBIOGET_FSCREENINFO,&finfo)){
printf("Error reading fixed information/n");
exit(2);
}

if (ioctl(fp,FBIOGET_VSCREENINFO,&vinfo)){
printf("Error reading variable information/n");
exit(3);
}

screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
/*這就是把fp所指的文件中從開始到screensize大小的內容給映射出來，得到一個指向這塊空間的指針*/
fbp =(char *) mmap (0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fp,0);
if ((int) fbp == -1)
{
printf ("Error: failed to map framebuffer device to memory./n");
exit (4);
}
/*這是你想畫的點的位置坐標,(0，0)點在屏幕左上角*/
x = 100;
y = 100;
location = x * (vinfo.bits_per_pixel / 8) + y * finfo.line_length;

*(fbp + location) = 100; /* 藍色的色深 */ /*直接賦值來改變屏幕上某點的顏色*/
*(fbp + location + 1) = 15; /* 綠色的色深*/
*(fbp + location + 2) = 200; /* 紅色的色深*/
*(fbp + location + 3) = 0; /* 是否透明*/
munmap (fbp, screensize); /*解除映射*/
close (fp); /*關閉文件*/
return 0;

}

因為這是對線性存儲空間的讀寫，所以代碼有點不清晰，不易理解。但是有了這個基本的代碼實現，我們可以很容易寫一些DrawPoint之類的函數去包裝一下低層的對線性存儲空間的讀寫。但是有了畫點的程序，再寫出畫線畫圓的函數就不是非常困難了。

這些就是我對FrameBuffer的初步研究，匆忙之間寫些東西不成文章,以後要寫些更高級一點的函數的實現。

 

好東西。感到好熟悉，十幾年前在DOS下寫圖形界面的程序就是讀寫0xa000那段內存，輸出漢字也沒問題。原來linux也能這樣用。有時間琢磨琢磨。

 

好貼。支持你的努力

 

好文章，讓我瞭解了fb是怎麼工作的。

 

Gtk Qt 是不是通過操作 fb 來畫圖的呢？
這樣畫的圖在鼠標移過時，圖就會被更新，那更新出來的圖，是存在那裡的呢？
fb 裡存放的數據是否存有正在看的電影的顯示呢？

 

強人+強貼..........

 

framebuffer 要比X-window-system低級。而GTK和QT是建立在Xlib上的，至於如何來實現鼠標那應該是X-server的事情了，在安裝X- window-system（debian）時會讓你選擇要不要內核的framebuffer支持，理論上選和不選都可以。如果不選，X會用它自帶的驅動 來實現對線性內存空間的讀寫改變屏幕顯示。

這只是一個機制，實現不一定非要framebuffer不可。但在Linux（kernel>2.2）上用framebuffer來實現X總是可以的。

 

嘿嘿，又長見識了，望樓主多分享經驗及心得，值得加精鼓勵;)

 

希望多看到這種文章

 

有個叫 direct frame buffer 的項目，做的類似於樓主所說的事情：
http://www.directfb.org/

 

謝謝樓主分享，回去好好研究一下

 

qt的嵌入式版qte使用的是framebuffer