LCD frame buffering device favorites

Framebuffer is an interface provided by Linux for display devices, it allows upper-layer applications to directly read and write the display buffer in graphic mode. This operation is 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 completed by the framebuffer device driver. Frame buffering is widely used. In Linux desktop systems, XWindow servers use frame buffering to draw windows. In particular, frame buffering devices can display Chinese Character arrays, making it the only feasible solution for Linux localization.
The device file corresponding to the frame buffer device is/dev/FB *. If the system has multiple video cards, multiple frame buffer devices can be supported in Linux, up to 32, they are/dev/fb0 ~ /Dev/fb31, 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 numbers are 29, and the secondary device numbers are 0 to 31, respectively corresponding to/dev/fb0 ~ /Dev/fb31

Through/dev/FB, there are several main application operations:
1. read/write/dev/FB
It is equivalent to a read/write screen buffer.
CP/dev/fb0 TMP copy the content of the current screen to a file
Cp tmp>/dev/fb0: The image file TMP is displayed on the screen.
2. Map operations
Because Linux works in protection mode, each application has its own virtual address space, and the application cannot directly access the physical buffer address. To this end, Linux provides the MMAP function in the file_operations structure for file operations, so that the file content can be stored in 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 addition, several processes can be mapped to the same display buffer. In fact, all applications that use frame buffering devices use ing operations to display images.
3. I/O Control
For frame buffering devices, IOCTL operations on device files can be used to read/set display devices and screen parameters, such as resolution, number of display colors, and screen size. IOCTL operations are completed 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 current display screen parameters. The size of the screen buffer can be calculated based on the 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.

Note:Memset: fills in a given value in a memory block. It is the fastest way to clear large struct or array.
Memcpy: it is used to copy a byte in memory from one area of memory to another regardless of the content.

At the lab at on January 26, December 9

____________________________________________________________________

Typical program section analysis:

   #include

int main(){

        int fbfd = 0;

Struct fb_var_screeninfo vimnfo; struct fb_var_screeninfo finfo; long int screensize = 0;/* Open the device */fbfd = open ("/dev/fb0", o_rdwr); IOCTL (fbfd, fbioget_fscreeninfo, & finfo); IOCTL (fbfd, fbioget_fscreeninfo, & vimnfo); screensize = vimnfo. xres * vimnifo. yres * vimnfo. bit_per_pixel/8; FBP = (char *) MMAP (0, screensize, prot_read | prot_write, map_shared, fbfd, 0 );
......
}

Write the frame buffer driver

The frame buffer device is a character device. It is designed to establish an automatic transmission channel between a specified memory and LCD by configuring the mx1 register. In this way, any program can change the display content on the LCD as long as it modifies the data in the memory. The driver of the frame buffer device also adopts the "file layer-driver layer" interface mode. At the file level, Linux defines the following:

Static struct file_operation fb_fops = {

Owner: this_module
Read: fb_read,/* read operation */
Write: fb_write,/* write operation */
IOCTL: fb_ioctl,/* control operation */
MMAP: fb_mmap,/* ing operation */
Open: fb_open,/* open operation */
Release: fb_release,/* close operation */

}

All member functions are defined in the file Linux/dev/vimdeo/fbmem. C.

Due to the special nature of the display device, the driver layer interface should not only define the underlying functions, but also have some functions to record the device status. Linux defines the driver test for frame buffer devices as an excuse for the struct fb_info structure, which is defined in include/Linux/FB. h.

On the morning of October 11, December 10

____________________________________________________________________

  Description of several key members used in the driver Fb_info: Records all information about the frame buffer device, including device parameters, status, and operation function pointers. Each frame buffer device must correspond to an fb_info structure. Among them, the member variable modename is the device name, fontname is the display font, and fboops is the pointer to the underlying operation function. These functions need to be compiled by the driver. The members fb_var_screeninfo and fb_var_screeninfo are also struct. Var_screeninfo records the number of parameters that can be modified by the user, including the screen resolution and the number of bits per pixel. Xres in fb_var_screeninfo defines the number of vertices in a row on the screen, yres defines the number of vertices in a column on the screen, and bits_per_pixel defines how many bytes each vertex is represented. The fb_fix_screeninfo records the parameters of the display controller that cannot be modified by the user, such as the physical address and length of the screen buffer area. When a buffer device is mapped, the corresponding physical address of the buffer is obtained from fb_fix_screeninfo. The data members mentioned above must be initialized and set in the driver. To write the frame buffer driver, follow these steps: 1. Compile the initialization function:The initialization function first initializes the LCD controller by writing the display mode and number of colors set by the Register, and then allocates the LCD display buffer. In Linux, you can use the kmalloc function to allocate a continuous space. For example, the LCD display mode is 320*240, 16-bit color, and the display buffer location to be allocated is 320*240*2 = K bytes. The buffer zone is usually allocated in the large-capacity off-chip SDRAM, the start address is stored in the LCD control register. Finally, initialize an fb_info structure, fill in the member variables, and call register_framebuffer (& fb_info) to register fb_info into the kernel. 2. Compile the member functions corresponding to the function pointer fb_ops in the fb_info structure:For the simple implementation of the embedded system, you only need the following three functions: struct fb_ops {...... INT (* fb_get_fix) (struct fb_fix_screeninfo * Fix, int con, struct fb_info * info); int (* fb_get_var) (struct fb_var_screeninfo * Fix, int con, struct fb_info * info ); INT (* fb_set_fix) (struct fb_fix_screeninfo * Fix, int con, struct fb_info * info );......} struct fb_ops in include/Linux/FB. h. These functions are used to set/obtain the member variables in the fb_info structure. When the application performs IOCTL operations on device files, it calls them. For example, for fb_get_fix (), the application passes in the fb_fix_screeninfo structure and assigns values to its member variables in the function, smem_start (buffer address) and smem_len (buffer length) are returned to the application. The input parameter of the fb_set_var function is fb_var_screeninfo. In the function, you must assign values to xres, yres, and bits_per_pixel. After the driver program is compiled, developers can choose to dynamically load the module by compiling its translation space, or compile it into the kernel statically. LCD APIThe LCD API is a set of application layer programming portals. It maps the physical address of the screen buffer to a virtual address in the user space, and then the user can access the screen buffer through this virtual address, drawing on the screen. LCD _initalize maps 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 the screen. LCD _putpixel is the basis for drawing, where straight lines, rectangles, ovans, and circles are inherited algorithms. When using this function to display characters, use the/usr/local/src/example/bin/hz16 character library file. LCD display principle:LCD is a display device based on the photoelectric effect of liquid crystal. The working principle of a liquid crystal display is to use the physical characteristics of the liquid crystal. when the power is on, the liquid crystal arrangement becomes orderly, making the light easy to pass through. when the power is not on, the arrangement becomes chaotic and prevents the light from passing through. That is, when a liquid crystal works, it uses external light and does not emit light itself. Therefore, compared with CRT, the liquid crystal display consumes less power. There are two main types of bit liquid crystal lighting used in LCD: Transfer Type and reflection type. For a transfer-type screen, you need to use an additional light source for backlight. The lighting source is installed behind the LCD. In normal light and dark light, the transmission LCD has good display performance, but it is difficult to identify the display content outdoors, especially in sunlight. Reflective screens do not require additional lighting power and use ambient light. In this way, reflective screens do not have backlights. Therefore, these screens are outdoors or in rooms with plenty of light, but in normal indoor light, the display effect is not as good as that of backlight transmission. Grayscale display principle: In fact, the LCD display is not set to different brightness to drive each pixel. The object element is either displayed or closed. A common indicator of the LCD display is its response time. The response time refers to the time taken for a pixel from display to close, typically several hundred Ms. A debugging technique is used to drive each pixel, that is, each pixel is driven by a part of the entire fixed time period. The LCD controller has a 16-cycle counter for generating a 16-cycle interval. When driving a pixel, it reads the half-byte data in the color register as indicated by the frame buffer data. This data determines the number of pixels displayed in the interval during the 16-week period. For example, if the value is equal to 4, each four clock cycles of the pixel are displayed once, which is equal to 4/16 of the 16-cycle interval. The image is displayed at 1/4 of the maximum brightness. Color Display principle:During color display, each pixel point has three sub-color pixels (RGB). The gray-scale display technology is applied to color display. Each sub-Color Pixel has 15 levels of sensory effect. One of the 15 concentrations in three RGB colors can be used to drive one pixel point. For example, the LCD controller is programmed to be In the 4bpp mode and supports up to 15*15*15 = 3 375 different colors. In the 2bpp mode, 64 different colors are supported; in 1bpp mode, 8 different colors are supported. For A 1/4 VGA display, the actual number of pixels is equal to 320*400*4 = 921600 bits or 115200 bytes, smaller than the maximum frame buffer limit (128 K) mentioned above. Another display feature is the refresh rate, which refers to the frequency at which the entire data frame is rewritten to the display screen. If data writing is too slow, the display quality will be affected. If it is too fast, the display response time cannot keep up with the change of the pixel driving status. The recommended speed for most display screens is 70 ~ 80Hz