Android display SW Architecture Analysis (2)

Android display SW Architecture Analysis

 

The following describes the layers
:

*

Blue part

-User space applications

Application Layer, including
Android
The application, framework, and system Runtime Library are related to the underlying system Runtime Library, and the display-related
Android
Of
Surface manager,

It manages the display subsystem and provides multiple applications.
2d
And
3D
Seamless fusion of layers.

*

Black

Color part

-Hal
Layer, in 2.2.1
Some will be introduced

*

Red part

-Linux Kernel
Layer

Linux Kernel

Which is related to the display part
Linux
Of
Framebuffer
, It is
Linux
Some driver interfaces are displayed in the system.
Linux
Working in protection mode,
User
Space applications cannot directly call the driver of the video card to directly screen the video,
Framebuffer
This mechanism imitates the function of a video card and abstracts the hardware structure of the video card.
Framebuffer
Read/write operations on the video memory directly. You can
Framebuffer
It is regarded as an image showing the memory. After it is mapped to the process address space, you can directly perform read/write operations, and the 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

-

HW


Driver Layer

This part can be seen as the driver of Qualcomm's graphics card, and is related to some of Qualcomm's display hardware and peripherals.
LCD
Related drivers are defined here. For example, some features of the above video card are initialized here
MDP
And
Mddi
Related drivers are also defined here.

User space display

Features

Here, the user space
Is the upper-layer section related to the application (see the blue section in the reference section ).
Space interaction is calledHal
-HW login action Layer
.

Hal
It is actually a user space driver. If you want
Execute these drivers on a hardware platform. Which defines android
For each hardware device, such as display chip, sound, digital camera, GPS
, GSM
And so on.

Hal
There are several reasons:

1,


Not all hardware devices have standard Linux Kernel
.

2,


Kernel Driver
GPL
. Some device manufacturers make public hardware drivers for no reason, so they only go to Hal
Method to bypass GPL
.

3,


For some hardware, Android
There are some special requirements.

In the display
Part, hal
Implementation Code
In copybit. c
The application can directly operate on 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 parameters

CTX-> device. Get = get;

CTX-> device. Bits = blit_copybit;
//
Transmit display data

CTX-> device. Stretch = stretch_copybit;

CTX-> malpha = mdp_alpha_nop;

CTX-> mflags = 0;

CTX-> MFD = open ("/Dev/graphics/fb0
", O_rdwr, 0 );
//
Enable the device

Kernel space display

Features

The kernel here
Space (with the display
Related) is Linux
Platform-based FB
Device (refer to the Red Section ). Next we will introduce FB
Device.

FB
Framebuffer
. Framebuffer
It is a hardware device that can extract graphics. It is a good interface for users to access the graphic interface. With framebuffer
Your applications do not need to have a deep understanding of the underlying driver to make good graphics. For the user, IT and/dev
There is no difference between the following other devices.

Framebuffer
As a piece of memory, you can either 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
Device Driver.

From the user's perspective, frame buffering devices and other
The following device is similar, it is a character device, usually the master device number is 29
The number of sub-device numbers that define the number of frame buffers.

In Linux
In the system, devices are processed as files. All files include the device files
Provides unified operation function interfaces. The above struct is Linux
For FB
The operation function interface provided by the 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 video storage. You need to map
Virtual Address)

Because Linux
Working in the protection mode, each application has its own virtual address space, and the physical buffer address cannot be directly accessed in the application. Therefore, Linux
Operate file_operations in the file
The MMAP
Letter
To 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, you can read
Write this virtual address to access the screen buffer and draw 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 that the frame buffer driver does not work much for developers.

3

),
I/O


Control:

For frame buffering devices
IOCTL

Operation readable
/

Set parameters for the display device and screen, such as resolution, number of colors, and screen size.
IOCTL

Is completed by the underlying driver.

Note

: For more information, see
Fbmem. c

.