Android display Architecture Analysis 2-SW Architecture Analysis

The following describes each layer:

* Blue part-user space application

The application layer, including the Android Application, framework, and system Runtime Library. The underlying layer is related to the system Runtime Library, and the display is related to the surface manager of Android, it manages the display subsystem and provides seamless integration of 2D and 3D layers for multiple applications.

* Black part-Hal layer, which will be introduced in section 2.2.1

* Red part-Linux kernel layer

Linux Kernel, which is related to the display part of the Framework buffer of Linux. It is the display part of the driver interface in Linux. In Linux, in protection mode, the user space applications cannot directly call the driver of the video card to directly screen the video. The framebuffer mechanism imitates the function of the video card and abstracts the hardware structure of the video card, you 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
Framebuffer device driver.

* Green part-HW driver layer

This part can be seen as the driver of Qualcomm's graphics card. Drivers related to some of Qualcomm's display hardware and peripheral LCD are defined here, for example, some features of the above video card are initialized here, and MDP and mddi drivers are also defined here.

User space display

Here, the user space is the upper layer of the application (see the blue section in the reference), and the part of interaction with the kernel space is called the HAL-HW wait action layer.

Hal is actually a user space driver. If you want to run Android on a hardware platform, you can basically complete these drivers. It defines Android requirements for various hardware devices, such as display chips, sound, digital cameras, GPS, and GSM.

There are several reasons for HAL:

1. Not all hardware devices have standard Linux kernel interfaces.

2. the kernel driver is copyrighted by GPL. Some device manufacturers do not disclose hardware drivers for any reason, so they use Hal to bypass GPL.

3. Android has some special requirements for some hardware.

In the Display Section, the Hal implementation code is in copybit. C. The application can directly operate these interfaces. The specific interfaces are as follows:

Struct copybit_context_t * CTX = malloc (sizeof (struct copybit_context_t); memset (CTX, 0, sizeof (* CTX); CTX-> device. common. tag = hardware_device_tag; CTX-> device. common. version = 0; CTX-> device. common. module = module; CTX-> device. common. close = close_copybit; CTX-> device. set_parameter = set_parameter_copybit; // set the CTX-> device parameter. get = get; CTX-> device. bits = blit_copybit; // send the display data CTX-> device. stretch = stretch_copybit; CTX-> malpha = mdp_alpha_nop; CTX-> mflags = 0; CTX-> MFD = open ("/dev/graphics/fb0", o_rdwr, 0 ); // open the device

Kernel space display

The kernel space (related to display) is the FB device on the Linux platform (refer to the red part in ). The following describes the FB device.

FB is short for framebuffer. Framebuffer is a hardware device that can extract graphics. It is a good interface for users to access the graphic interface. With framebuffer, your applications can make good graphics without having to have a deep understanding of the underlying driver. For a user, it is no different from other devices under/dev.

Framebuffer is regarded as a piece of memory, which can be used to write data to this memory or read data from this memory. 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.

From the user's point of view, the frame buffering device is similar to other devices located under/dev. It is a character device. Generally, the master device number is 29, and the next device number defines the number of frames buffered.

In Linux, devices are processed as files. All files, including device files, provide unified operation function interfaces. The above struct is the operation function interface provided by Linux for the FB device.

1) read/write interface, that is, read/write screen buffer (the application may not necessarily call this interface)

2) ing (MAP) operation (the user space cannot directly access the physical space of the display and storage, and the user space must be mapped to a virtual address)

Because Linux is working in protection mode, each application has its own virtual address space, and the physical buffer address cannot be directly accessed 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 the parameters of the display device and screen, such as resolution and number of colors, the screen size. The IOCTL operation is completed by the underlying driver.

NOTE: For the above part, see the file fbmem. C.