In addition to the previously mentioned camera recording driver basics using MIPI and V4L2, there is also imaging display technology.
This article summarizes the common interfaces for screen display, MIPI, as well as the DRM driver framework and touch technology commonly used in display driver development. Finally, it introduces dual-screen technology, which helps in understanding the fundamentals of display driver operation.
1. Display Hardware Interfaces
The current hardware interfaces for embedded touch display screens mainly consist of two parts, corresponding to the hardware screen integration. The software includes the MIPI-DSI interface for display and the I2C touch control interface.
The MIPI-DSI mode controls the LCD display. The MIPI DSI interface features high speed, low power consumption, and differential signal transmission, making it suitable for various display devices and application scenarios.
In addition to the MIPI interface, the display hardware also includes PWM backlight brightness, power supply, GPIO, and other pins.
The touchscreen is implemented by a separate touch chip, which is generally integrated with the display. The mainboard controls the touch screen through I2C and GPIO.
The I2C bus exchanges touch data with the touch chip, while the GPIO chip controls mainly includes power enable pins, touch interrupt pins, and touch reset pins.
The schematic is as follows:
Packet format: Data is transmitted using packet format, including long packets and short packets. Long packets are mainly used for transmitting large amounts of image data, while short packets are mainly used for transmitting commands and reading/writing registers.
2. DRM Software Driver Framework
The imaging display DRM (Direct Rendering Manager) framework is the driver framework for graphics cards, responsible for displaying rendered images on the LCD screen.
In the Android DRM software architecture, the DRM Framework API module provides API interfaces for the APP at the Framework layer, which communicates with the DRM Manager module in the DRM process through the Binder communication mechanism for management. The DRM Plugins are modules that implement DRM rights management, digital content decryption, and other functionalities.
The DRM architecture directory for the RK3399 platform is /kernel/drivers/gpu/drm/rockchip/. The drm_drv.c file’s drm_bind() function creates and registers the DRM device.
On the human-computer interaction control terminal, the following commands can be used to view the graphics card and connection status of DRM.
| Use ls /sys/class/drm to view registered graphics cards |
|---|
| ls /sys/class/drm/*** to check connector status |
3. Touch Software Driver
The essence of a touchscreen is sensing technology, which has evolved from single-point touch to multi-point touch. The most common touchscreens are resistive and capacitive touchscreens.
Taking the GT9xx series touch chip as an example, the driver directory is /kernel/drivers/input/touchscreen/gt9xx.c;
The job of the driver software is to port the relevant drivers and complete the I2C interface configuration in the device tree.
4. Dual-Screen Display Functionality Applications
By using two displays in combination and adapting the corresponding software, the current dual-screen display functionality can be achieved.
Dual screens can display the same content or different content, corresponding to dual-screen mirroring and dual-screen extension.
Dual-screen mirroring is applied in the camera field, enabling front and back screen display applications, where the front screen is used for selfies, and the back screen serves as the main screen for touch and display functionality.
Dual-screen extension in the robotics field can display images returned from a remote robot camera on the upper screen, while the lower screen shows the robot’s status and control information. Each screen handles its own triggering events, thus achieving simultaneous reconnaissance and control in applications, improving efficiency.
5. Dual-Screen Display Software Approach
The dual-screen display is implemented by modifying the surfaceflinger and inputflinger in the /framework/native/ directory.
As two native processes of Android, surfaceflinger is mainly responsible for composing layers, which together form the interface we see, while inputflinger handles the event input subsystem’s framework and flow.
In the framework’s touch functionality framework entity, there is a displayID member to distinguish between the main screen and the secondary screen. When the touch event’s displayId corresponds to the main screen, the event is sent to the main screen’s TouchedWindow; when the displayId corresponds to the secondary screen, the event is sent to the secondary screen’s TouchedWindow.
The display status can be checked with the following commands:
| Command List |
|---|
| logcat | grep surfaceFlinger // Check hardware abstraction layer display status |
| logcat | grep inputFlinger |
| cat /d/dri/0/summary // Check VOP status |
| ls /sys/class/drm // View registered graphics cards |
