Android Graphic System Analysis and transplantation-vi. framebuffer Research

1. Development History of framebuffer

Computer researchers have long been discussing the advantages of framebuffer, but have been suffering from the inability to produce a computer with enough memory. In 1969, Bell's laboratory's joanmiller tested the first known framebuffer. The device displays a 3-digit picture. However, it was not until 1970s that progress on the memory chip of the integrated circuit made it possible to create a framebuffer that could display standard video images.

In 1972, Richard Shoup designed a superpaint system at the Xerox Palo Alto Institute, which has 311,040 bytes of memory and can store 640*480 pixels and 8-bit images. The memory is distributed across 16 circuit boards, with each board equipped with multiple 2--bit chip selection. To make the entire system work normally, Richard Shoup's design must ensure that the entire framebuffer is implemented as a 307,200-byte chip for registration and can be synchronized with TV signals. The initial weakness of this design has been revealed, that is, the memory cannot be accessed randomly. Of course, you can access the specified scanning line at the specified position. As a result, the system has a huge potential defect, resulting in a latency of 33 Ms when writing data to framebuffer.

At the same time, Richard Shoup can use the superpaint system to create an early Digital Video Capture System. By synchronizing the output signal to the input signal, Richard Shoup can overwrite the data of each pixel. Richard Shoup has also tried to use a color table to modify the output signal, which allows the superpaint system to produce a variety of colors beyond the color limit of 8-bit data. This system will become a common system in the computer frame buffer zone in the near future.

In 1974, Evans and Sutherland released the first commercial version of framebuffer, costing $15,000. It can produce 512*512 pixel resolutions in 8-bit grayscale mode and become a benefit for researchers who do not have the resources to build framebuffer for themselves. In the near future, New York University of Technology will use three systems of Evans and Sutherland to create the first 24-bit color system. Each framebuffer is connected to an RGB color output, one microcomputer controls three devices as one device.

By the end of 1970s, the rapid development of integrated circuit technology made it possible for home computers to contain low-color framebuffer. Although low-color framebuffer is always ridiculed for its poor performance compared to more precise graphics devices such as Atari 400 used in some computers, framebuffer becomes a standard in personal computers. Today, almost all computers with graphic processing capabilities use framebuffer to generate video signals.

In 1980s, framebuffer became popular in high-end smart terminals. SGI, sun, HP, Dec, and IBM have released framebuffer versions for their computers. These framebuffer versions are generally of higher quality than most home computers and are used on television, printing, computer modeling, and 3D graphics technology.

Thanks to its excellent graphic processing capabilities, amiga has created a broad framebuffer market based on graphics cards. It is worth mentioning that the graphics card used in the Amiga a2500 UNIX computer, it was the first host server computer in 1991 that implemented a graphical environment using X11 servers and a high-resolution (1024*1024 or 1024*768,256 color) GUI of the open look GUI. This graphic card mounted on a2500 UNIX is called a2400. It is a Graphics Board based on the Tms34010 graphics processor of Texas Instruments. The clock frequency is 50 MHz and it is a completely only co-processor. The a2410 graphics card was jointly developed by Amiga and Lowell University. It is worth mentioning that amiga's framebuffer is based on the impact in the video integration series of gvp.
Implemented by vision iv24 graphics card, it has the ability to mix Synchronous lock signals, color and TV signals into a 24-bit framebuffer, until today, it has been active in the market, dctv, firecracker, and harlequin are still in use.

2 concepts related to framebuffer

Framebuffer is translated as a frame buffer driver in Chinese. It is a driver interface that appears in the 2.2.xx kernel.

Linux is working in the protection mode, so user-mode processes cannot use the interrupt call provided in the graphics card BIOS as DOS to achieve direct screen writing, linux abstracts the framebuffer device for the user-state process to directly write the screen. The framebuffer mechanism imitates the function of the video card, abstracts the hardware structure of the video card, and can directly perform operations on the video memory through the read and write operations of framebuffer. Users can regard framebuffer as an image showing the memory. After ing it to the process address space, they can directly perform read/write operations, and write operations can immediately respond to the screen. 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.

But framebuffer itself does not have any ability to operate data, so it is better than a pool that temporarily stores water. The CPU puts the result after calculation into this pool, and the pool then streams the result to the monitor without processing the data. Applications can also directly read and write the contents of this pool. In this mechanism, although framebuffer requires the support of a real video card driver, all the display tasks are completed by the CPU, so the CPU burden is very heavy.

Frame Buffer drivers are widely used. In Linux desktop systems, the X Window server uses frame buffer to draw windows. In particular, frame buffering can display Chinese character lattice, making it the only feasible solution for Linux localization.

In the developer's opinion, framebuffer is essentially 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 refresh cache framebuffer or refreshbuffer. The frame here refers to the entire screen range.

The frame cache has an address in the memory. By constantly writing data to framebuffer, the display controller automatically retrieves and displays data from framebuffer. 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. The content stored in the frame cache framebuffer is one frame at a time, and the video card will constantly refresh the framebuffer. 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 be at a resolution of X, it stores pixels and color values.

3 framebuffer usage Basics

The device files of framebuffer are usually/dev/fb0,/dev/Fb1, and so on.

Run # dd If =/dev/Zero of =/dev/FB to clear the screen.

If the display mode is 1024x7688-bit, run the command $ dd If =/dev/Zero of =/dev/fb0 BS = 1024 COUNT = 768 to clear the screen;

Run the command: # dd If =/dev/FB of = fbfile to save the content in FB;

You can write back the screen: # dd If = fbfile of =/dev/FB;

When framebuffer is used, Linux places the video card in graphic mode.

In applications, the framebuffer device is usually used by ing the framebuffer device to the process address space. For example, the following program opens the/dev/fb0 device and performs address ing through the MMAP system call, then use memset to clear the screen (Here we assume the display mode is 1024x7688-bit color mode, linear memory mode ):

Int FB;

Unsigned char * fb_mem;

Fb = open ("/dev/fb0", o_rdwr );

Fb_mem = MMAP (null, 1024*768, prot_read | prot_write, map_shared, FB, 0 );

Memset (fb_mem, 0, 1024*768); // This command should only be executed by the root user

The framebuffer device also provides several IOCTL commands to obtain some fixed information about the display device (such as the Display memory size) variable information related to the display mode (such as resolution, pixel structure, byte width of each scanned line), and color palette information in pseudo-color mode.

The framebuffer device can also obtain the type of the accelerated display card supported by the current kernel (obtained through fixed information), which is usually related to a specific display chip. For example, the latest kernel (2.4.9) supports acceleration of popular display chips such as S3, matrox, NVIDIA, and 3dfx. After obtaining the acceleration chip type, the application can map the memory I/O (memio) of the PCI device to the address space of the process. These memio are generally used to control the registers of the display card. By operating these registers, the application can control the acceleration function of a specific video card.

The PCI device can map its own control registers to the physical memory space. Then, access to these control registers becomes access to the physical memory. Therefore, these registers are also called "memio ". Once mapped to the physical memory, common processes in Linux can map these memory I/O to the process address space through MMAP, so that these registers can be directly accessed.

Of course, because different display chips have different acceleration capabilities, the use and definition of memio are also different. At this time, you need to write different acceleration functions for different types of acceleration chips. For example, most chips provide hardware acceleration for Rectangle filling, but different chip implementation methods are different, you need to write different functions for filling the rectangle for different chip types.

Framebuffer is only a device that provides Display memory and display chip registers ing from physical memory to process address space. Therefore, for applications, If You Want To program graphics on framebuffer, you also need to do a lot of work by yourself.

The procedure of framebuffer is 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 ing, you can directly read and write the screen buffer for plotting and image display.

4 frmaebuffer Internal Structure

The framebuffer device driver is based on the following two files:

1) Linux/include/Linux/FB. h

2) Linux/Drivers/Video/fbmem. c

The two files are analyzed below.

1. FB. h

Almost all the major structures are defined in this file. These structures include:

1) fb_var_screeninfo

This structure describes the features of the display card.

2) fb_fix_screeninfon

This structure is created after the video card is set mode. It describes the properties of the display card and cannot be modified during system operation. For example, the starting address of framebuffer memory. It depends on the set mode. When a mode is set, the memory information is provided by the display card hardware, and the memory location and other information cannot be modified.

3) fb_cmap

Describes the color ing information unrelated to the device. You can use the ioctl operation corresponding to fbiogetcmap and fbioputcmap to set or obtain the color ing information.

4) fb_info

Defines the current status of the video card. The fb_info structure is only visible in the kernel. In this structure, there is an fb_ops pointer pointing to the function set required for the driver to work.

5) struct fb_ops

The user application can use the ioctl () System Call to operate the device. This structure uses these operations that support IOCTL.

6) structfbgen_hwswitch

This structure fbgen_hwswitch abstracts hardware operations. Although it is not required, it is sometimes useful.

2. fbmem. c

Fbmem. C is in the center of the framebuffer Device Driver technology. It provides system calls for upper-layer applications and interfaces for specific hardware drivers at the next layer. These underlying hardware drivers need to use these interfaces to register themselves with the system kernel. Fbmem. C provides common interfaces for all device drivers that support framebuffer to avoid repeated operations.

1) global variables

Struct fb_info * registered_fb [fb_max];

Intnum_registered_fb;

These two variables record all instances of the fb_info structure. The fb_info Structure describes the current status of the video card. The fb_info structure of all devices is saved in this array, when a framebuffer Device Driver registers itself with the system, its corresponding fb_info structure will be added to this structure, and num_registered_fb will automatically add 1.

2) fbmem. c implements the following functions:

Register_framebuffer (structfb_info * fb_info );

Unregister_framebuffer (structfb_info * fb_info );

These two interfaces are provided to the underlying framebuffer device drivers. The device drivers use these two functions to register or deregister themselves with the system. All you need to do for the underlying device driver is to fill in the fb_info structure and then register or deregister it with the system.

5 double buffering mechanism

The first way to explain how multi-Buffers work is through a real-life instance. On a sunny day, when you want to change the water in the pool, and you cannot find the water pipe, you can only fill the pool with a barrel. When the barrel is filled with a tap, turn off the tap, go to the pool, put the water in, and then go back to the TAP to continue to repeat the above work, so that until the pool filled. This is similar to the single buffering process. When you want to pour water out of a bucket, you must turn off the faucet.

Now let's assume that you use two barrels for the above work. You will fill the first bucket and change the second bucket to the bottom of the faucet. In this way, you can pour the water in the first bucket into the pool within the time when the second bucket is filled, when you come back, you only need to replace the first bucket with the second bucket filled with water, when the first bucket starts to inject water, you will pour the water in the second bucket into the pool. Repeat this process until the pool is fully filled. It is easy to see that using this technology to fill the pool will be faster, but it also saves a lot of time waiting for the barrel to be filled up, and you can't do anything during this time, the faucet does not have to wait for the time from the barrel filled to your return.

When you hire another person to carry a fully filled bucket, this is a bit like how three buffers work. If it takes a long time to move the barrel, you can use more barrels to hire more people, so that the faucet will be filled with barrels.

In computer graphics, dual buffering is a drawing technology. This technology can make the drawing do not (at least reduce) Flash, tear, and other adverse effects, and reduce the waiting time.

The principle of the dual buffer mechanism is probably that all drawing operations save their drawing results in a system memory area, which is usually called the "back buffer )", after all the drawing operations are completed, copy the entire area to the Display memory. This copy operation is usually synchronized with the display light stack bundle to avoid tearing. The dual-buffer mechanism must require more Display memory and CPU consumption time than a single buffer, because the "post-buffer" needs to display memory, and the replication operation and waiting for synchronization require CPU time.

Based on the dual-buffer mechanism, page exchange can be realized.

Initial page switching status:

As shown in, because it is in the initial state, the drawing operation results are in the back buffer, while the screen displays the content in the front buffer. The drawing operation has not been completed yet.

After the Drawing operation is complete, the page conversion operation starts ,:

As shown in, the painting operation ends. The result of the next painting operation is to save the object in the forward buffer zone. The Display object on the screen points to the back buffer zone. At this time, the front buffer zone turns to the back buffer zone in the actual sense, the post-buffer is actually the front buffer, that is, the "Page switching" operation is implemented.

Sometimes multiple "post-Buffers" are also set in the page switching chain, which requires the support of the Multi-buffer mechanism.