Android core analysis (24)-display buffer management for Android GDI

Android GDI screen device management-Dynamic Link Library

The tall building starts from the ground and starts from the most rooted hardware frame buffer zone. We know that the display of framebuffer is a piece of memory in the system, and the work of GDI is to put the content to be output to a certain position in the memory of this segment. We start with basic points (pixels) and basic buffer operations.

1. Basic Knowledge: the format

For different LCD, the binary format of framebuffer is different and can be divided into two parts:

1) Point format: Usually depth, that is, the number of bits to represent a point.

1 bit indicates a vertex

Two digits indicate a vertex.

A 16-bit Vertex

32-bit indicates a point (alpha channel)

2) Intra-point format: RGB component distribution representation.

For example, for a common 16-bit representation of a vertex

1. 2. Conversion between formats

Therefore, the screen output is actually a value ing relationship. We can convert the following vertex format,

The source format may come from the monochrome bitmap and color bitmap. For a specific target machine, our target format may be a type, such as the 16-bit (5/6/5) format. In fact, there is only one format conversion, that is, the slave target format is a 16-bit format.

However, when designing GDI, there is a basic requirement for good portability. Therefore, we must consider the conversion between different formats of LCD. Therefore, the following main operations are involved in the driver of GDI:

Regional Operations: The most common operation we do on the display buffer zone is block handling. As a result, many application processors use the hardware Graphics Accelerator to perform regional shipping: B. From the perspective of our main operations, there are two directions:

1) memory area to screen area

2) screen area to screen area

3) screen area to memory area

4) memory area to memory area

In this case, we need to note that because the memory between different processes in Linux cannot be accessed freely, the usage of each Android Application in the memory area and the screen buffer becomes very complex. In Android design, there are many layers of management in the screen buffer and Display memory buffer. The top layer objects can be freely transmitted between processes, however, the buffer content uses the shared memory mechanism.

Based on the above basic knowledge, we can know:

(1) The meaning of config and its format in the code. It also understands the significance of compatibility: the use of the same hardware point description object

(2) moving all screen shapes shows the result of buffer movement.

1.2 Graphics Accelerator

All application Processors may have Graphics accelerators. Different Application Processors may have different processing methods for their Graphics accelerators. For 2D acceleration, they can all be attributed to B. Most of them are data handling, amplification, and reduction, and rotation.

 

2. Buffer abstraction definition for Android

Different hardware has different hardware graphics acceleration devices and buffer memory implementation methods. The abstract task of the android gralloc dynamic library is to eliminate the differences between different devices. In the upper layer, the same method and object appear. Hide the buffer operation details on the Moudle layer. Android uses the dynamic link library gralloc. XXX. So to encapsulate the underlying details.

2.1 local definition @ Hardware/libhandware/modules/gralloc

Each dynamic link library calls an interface with the same name:

1) Hardware Graphics Accelerator Abstraction: acceleration of blitengine and copybit.

2) Hardware framebuffer Memory Management

3) shared Cache Management

The abstract behavior of the dynamic link library is investigated from the data relationship: the content of the dynamic link library is completely packaged in the hierarchy: hardware. c @ Hardware/libhardware. /System/lib/HW/gralloc. XXX. So dynamic library file. The abstract result is obtained from the gralloc. H (handware/libhardware/include/hardware) file: hw_get_module extracts hal_module_info_sym (sym variable) from gralloc. XXX. So)

From the external data structure, we can see this layout in @ gralloc. cpp:

Static struct hw_module_methods_t gralloc_module_methods = {

Open: gralloc_device_open

};

Struct private_module_t hal_module_info_sym = {

Base :{

Common :{

Tag: hardware_module_tag,

...

ID: gralloc_hardware_module_id,

Name: "graphics Memory Allocator module ",

Author: "The Android open source project ",

Methods: & gralloc_module_methods

},

Registerbuffer: gralloc_register_buffer,

Unregisterbuffer: gralloc_unregister_buffer,

Lock: gralloc_lock,

Unlock: gralloc_unlock,

},

Framebuffer: 0,

Flags: 0,

Numbuffers: 0,

Buffermask: 0,

...

};

What object have we set up to support buffer operations?

Buffer_handle_t: external interface.

Methods. Open, registerbuffer, unregisterbuffer, lock, unlock

The following is the structure relationship between the external interface and the internal object. This type of structure makes full use of the data arrangement feature of C struct: the basic structure is placed at the beginning, and the local private is placed at the end, this satisfies the abstract needs.

Typedef const native_handle * buffer_handle_t;

Private_module_t hal_module_info_sym refers to the dynamic link library interface exposed. Through this interface, we can directly use this object.

You cannot see the figure above clearly. You can look at it with a different look:

Several interface functions:

(1) fb_post

The actual address of the frame buffer does not need to be reported to the upper layer. All operations are completed through fb_post.

 

The fp_post task is to pass the content of a buffer to the hardware buffer. There are two implementation methods:

 

 

 

 

(Method 1) You do not need to copy the buffer. You need to switch the buffer after framebuffer to the front buffer, and then tell the FB driver to switch the DMA source address through ioctrl. The premise of this implementation is that the Linux kernel must allocate at least two physical memory buffers and ioctrol for switching, which enables fast switching.

(Method 2) use copy. If the kernel is not modified, the copy method is used in the adaptation layer, but this is time-consuming.

 

 

(2) The main function of gralloc is to complete:

1) enable the screen device "/dev/fb0" and map the hardware display buffer.

2) provides an interface for allocating shared display caches.

3) provide the biltengine interface (to package the hardware accelerator)

(3) gralloc_alloc outputs the buffer_handle_t handle.

This handle is the basic basis for sharing. Its basic principles are described in detail in the following sections.

3. Conclusion

To sum up,/system/lib/HW/gralloc. XXX. So is a dynamic link library related to the hardware system. It can also be called the hardware abstraction layer of Android. It implements the Hardware Abstraction interface standard for Android and provides Display memory allocation mechanisms and copybit acceleration. How to implement these functions is related to the hardware platform, so we can see that there are different configuration relationships with different hardware architectures.