Frame Buffer in Linux)

Frame Buffer is an interface provided by Linux for display devices. It abstracts the video into a device, it allows upper-layer applications to directly read and write the display buffer in graphic mode. Such operations are abstract and unified. Users do not have to worry about the location of Physical video memory, page feed mechanism, and other details. These are all driven by the Framebuffer device.

Frame buffering is widely used. In linux desktop systems, Xwindow servers use frame buffering to draw windows. In particular, frame buffering can display Chinese character lattice, making it the only feasible solution for Linux localization.

In essence, Linux FrameBuffer only provides hardware abstraction for graphics devices. In the developer's view, FrameBuffer is a display cache. Writing data in a specific format to the display cache means outputting content to the screen. So FrameBuffer is a whiteboard. For example, for a 16-bit FrameBuffer, the two bytes in FrameBuffer represent a point on the screen, from top to bottom, from left to right, the linear relationship between screen position and memory address is sequential.

The frame cache can be anywhere in the system memory. The Video Controller refreshes the screen by accessing the frame cache. Frame cache is also called frame buffer or refresh buffer. The Frame here refers to the entire screen range.

The frame cache has an address in the memory. By constantly writing data to the frame buffer, the display controller automatically retrieves data from the frame buffer and displays the data. All images share the same frame cache in memory.

When the CPU specifies that the display controller works, the display controller obtains data and commands from the CPU control to the specified place. The current data is generally retrieved from the display memory. If the Display memory does not exist, it can be retrieved from the memory, and the memory can not be stored, but from the hard disk. Of course, it is not the memory, but to save the memory, it can be stored in the hard disk, then, use the command control to display the Controller for retrieval. Frame Buffer, which stores a Frame and a Frame. The video card keeps refreshing the Frame Buffer. If this Frame is not captured, it will be discarded, that is, it is real-time. Each frame, whether Stored in the memory or in the video memory, is an explicit message. If each frame is assumed to have a resolution of X, it stores pixels and color values.

The device file corresponding to the frame buffer device is/dev/fb *. If the system has multiple display cards, Linux supports multiple frame buffer devices, up to 32, they are/dev/fb0 to/dev/fb31 respectively, while/dev/fb is the current default frame buffer device, usually pointing to/dev/fb0. Of course, it is enough to support a display device in an embedded system. The frame buffer device is a standard character device. The primary device number is 29, and the secondary device number ranges from 0 to 31. Corresponding to/dev/fb0-/dev/fb31 respectively. Through/dev/fb, application operations mainly include:

1. read/write/dev/fb: equivalent to the read/write screen buffer. For example, the cp/dev/fb0 tmp command can be used to copy the content on the current screen to a file, while the command cp tmp>/dev/fb0 will display the tmp on the screen.

2. map operation: since Linux is working in protection mode, each application has its own virtual address space, so it cannot directly access the physical buffer address in the application. Therefore, Linux provides the mmap function in the file_operations structure for file operations, which can map the file content to the user space. For frame buffer devices, you can map the physical address of the screen buffer to a virtual address in the user space, then, the user can access the screen buffer by reading and writing the virtual address, and draw a picture on the screen. In fact, all applications that use frame buffering devices use ing operations to display images. Since all the ing operations are completed by the kernel, we will see below that there is not much work left by the frame buffer driver for developers.

3. I/O Control: For frame buffering devices, ioctl operations on device files can be performed to read/set display device and screen parameters, such as resolution, number of colors, and screen size. Ioctl operations are performed by the underlying driver.

The general steps for operating/dev/fb in an application are as follows:

1. Open the/dev/fb device file.

2. Use ioctrl to obtain the parameters of the current display screen, such as the screen resolution and the number of bits per pixel. The screen buffer size can be calculated based on screen parameters.

3. Map the screen buffer to the user space.

4. After the ing, you can directly read and write the screen buffer for plotting and image display.

The typical program section is as follows:

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

}

1 2 Next Page