/Dev/fb0 getting started exercise (Linux framebuffer)

We all know that Unix/Linux systems are command-driven. The most basic system is the command line interface (that is, the interface like DOS ). X-window-system is a graphical System on Unix/Linux. It controls hardware through X-server. However, some Linux distributions may display images on the screen during boot. At this time, the images cannot be completed by X. What is the mechanism? The answer is framebuffer.
Framebuffer is not a graphic system, not a window system. It is lower than X. In short, framebuffer is a mechanism. This mechanism maps each point on the screen into a linear memory space. The program can simply change the value of this memory to change the color of a certain point on the screen. The high portability of X comes from this mechanism. No matter in that graphic environment, as long as this mechanism is implemented, X can be run. Therefore, the corresponding Version X has been transplanted on almost all platforms.
Well, let's talk less about it. Let's take a look at what you can do with framebuffer. First, check if you have the corresponding driver: find out if there is a device file FB * under/dev/. This is a special file of the character class.
Code:
Ls-L/dev/fb0 CrW-RW ---- 1 root video 29, 0 Jan 27 :32/dev/fb0
If you do not have this file, you can also find other files such as/dev/Fb1,/dev/fb2.. If you cannot find these files, you have to recompile the kernel. Assume that the file/dev/fb0 exists. This is the device file of framebuffer.
With this, we can play with framebuffer. (The following operations do not have to be performed under X. You can start the virtual console of framebuffer)
Code:
CAT/dev/fb0> pull snap LS-l pull snap-RW-r -- 1 WSW 6291456 Jan 27 then snap
We get a file that is exactly 6 MB, and then perform the following operations:
Code:
Clear/* clear screen output */CAT capture snap>/dev/fb0
Is something strange happened? Is it a virus? Is the screen restored again? Don't worry,
Code:
Clear
In this way, the screen is normal.

Through the above operations, I think you have guessed it. File/dev/fb0 is the file that controls the color of each point on the screen. We can write a program to change the content of this file so that we can easily draw a picture on the screen :-)

I will write a small program below to test the properties of the screen.

# 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 );
}
The data structures struct fb_var_screeninfo and struct fb_fix_screeninfo are defined in/usr/include/Linux/FB. H, which have some interesting values: (they are all unsigned 32-bit integers)
 
In fb_fix_screeninfo
_ U32 smem_len is the size of/dev/fb0, that is, the memory size.
_ U32 line_length is the memory space occupied by a row of points on the screen, not the number of points on a row.
In fb_var_screeninfo
_ U32 xres ,__ u32 yres indicates the resolution in the X and Y directions, which is the number of points in the two directions.
_ U32 bits_per_pixel is the memory space occupied by each point.

Compile and run the above program. The result on my machine is as follows:
The mem is 6291456
The line_length is: 4096 t
He xres is: 1024
The yres is: 768
Bits_per_pixel is: 32
// This is very important and complete during debugging !!!!!
The memory length is exactly 6 m, each row occupies 4 m space, the resolution is 1024x768, and the color depth is 32 bits. You may have discovered something wrong. The number of points on the screen is 1024x768 = 786432, and each point occupies 32 bits. The total memory occupied by the screen is 32x786432 = 25165824 is 3145728 bytes, which happens to be 3 m, but the above program tells us that there is 6 m of storage space. This is because there are many buffer technologies in the modern graphics system, and there are two pages of screen data in the video memory, which is convenient and fast to change the screen content to achieve relatively high requirements such as animation. This buffer technology is a bit complicated. We will not discuss it at present. For us, only the 3 M memory is used to store the color data of the screen.
Now you should have a rough understanding of framebuffer. Then you will definitely want to draw something on the screen. Let's start by drawing a dot first. Let's talk about my idea: in Unix-like systems, everything is a file. The screen read and write operations can be converted to/dev/fb0 read and write operations. Then open/dev/fb0 with open, locate the position to be read/write with lseek, and call read or write to operate. With such a large segment of operations, we can complete reading or writing to a vertex. This method is too costly. Another way is to map/dev/fb0 to the memory space of the program process, and then get a pointer pointing to this bucket, so that you can easily read and write. But we need to know the ing and ing, which can be easily determined by the parameters obtained from the above program.
// Description and description of the key part of memory ing
# 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;
/* This is to map the content in the file referred to by FP from the beginning to the screensize size to get a pointer pointing to this space */
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 );
}
/* This is the coordinate of the point you want to draw. (0, 0) The point is in the upper left corner of the screen */
X = 100;
Y = 100;
Location = x * (vinfo. bits_per_pixel/8) + y * finfo. line_length;

* (FBP + location) = 100;/* blue color depth * // * direct value assignment to change the color of a certain point on the screen */
* (FBP + location + 1) = 15;/* green color depth */
* (FBP + location + 2) = 200;/* red color depth */
* (FBP + location + 3) = 0;/* Whether transparent */
Munmap (FBP, screensize);/* unmap */
Close (FP);/* close the file */
Return 0;

}
However, with this basic code implementation, we can easily write some functions such as drawpoint to wrap the Low-layer read/write operations on the linear storage space. However, it is not very difficult to write the function of drawing a circle with a painting point.

These are my preliminary research on framebuffer. I cannot write anything in a rush. I will write more advanced functions in the future.

From: http://hi.baidu.com/fsx92/item/bdbf90d8adab409f260ae738