1. Introduction to DRM (Direct Rendering Manager)
When developing traditional linux display device drivers, the FB driver architecture is usually used. With the performance upgrade of the graphics card: display overlay (menu level), GPU acceleration, hardware cursor, the traditional FB architecture cannot support it well. In addition, access conflicts for multiple applications are also Can't control well. In this context, DRM applications are born.
DRM is the management framework responsible for interacting with the graphics card in the Linux kernel. The user space can easily use the API provided by DRM to realize 3D rendering, video decoding and GPU computing.
1.1 History of DRM Development
In 1999, Precision Insight developed the DRI display framework for XFree86 4.0 Server for the first time to better adapt to 3DFX’s graphics card. After the first version of DRM code was produced, in the next few years, the list of graphics cards supported by DRM has been continuously updated. expansion.
In October 2008, Linux kernel 2.6.27 underwent a major source code reorganization: the entire source code of DRM was placed in the /drivers/gpu/drm/ directory, and the codes of different GPU manufacturers were also placed in their respective subdirectories.
In June 2014, the Atomic API was added to Linux 3.16, and many drivers switched to use these new APIs.
In 2018, 10 new DRM drivers based on the atomic framework were added to the Linux kernel.
1.2 Advantages of DRM architecture compared to FB architecture
DRM is currently the mainstream graphics display framework of Linux. Compared with the traditional FB architecture, DRM allows multiple programs to use video hardware resources at the same time, and manages resource requests and access of multiple programs. In summary, DRM is more adaptable to the increasingly updated display. The advantages of hardware and DRM are mainly reflected in:
DRM natively supports multi-layer composition, while FB does not natively support multi-layer composition.
FB does not support VSYNC, DMA-BUF, asynchronous update and fence mechanism, but DRM natively supports them all.
DRM manages GPU and Display drivers in a unified way, making software upgrade, maintenance and management more convenient.
1.3 DRM graphic display framework
Each GPU detected by DRM is used as a DRM device, and a device file /dev/dri/cardX is created and connected to it. From the perspective of the overall architecture, it is mainly divided into 3 main parts:
libdrm (interface library)
Encapsulate the underlying interface and provide a common API interface to the upper layer, mainly to encapsulate various IOCTL interfaces for easy reuse and code sharing.
KMS (Kernel Mode Setting)
When working normally, you need to set the mode of the graphics card or graphics adapter, which is mainly reflected in the following two aspects:
Update screen: display buffer switching, multi-layer compositing method control, and the display position of each layer.
Set display parameters: including resolution, refresh rate, power status (wake up from sleep), etc.
GEM (Graphics Execution Manager)
Provides memory management methods, mainly responsible for displaying buffer allocation and release.
Figure 1.1 DRM graphic display framework overview
Image source: https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:DRM_architecture.svg
1.4 DRM graphic display framework involves elements
This chapter introduces the functions of some key modules in the DRM framework and their role in the display link. The following figure shows the flow chart of APP calling DRM to screen display.
Figure 1.2 DRM graphic display framework block diagram
The following table provides an overview of the different components of the KMS and GEM models in DRM, supplemented by a description of the corresponding relationship between the Qualcomm platform code levels to deepen the correspondence between the architecture and the process.
2. DRM driver framework
2.1 DRM driver object introduction
Objects inside DRM are the core of the DRM framework. The blue part in the figure below is the abstraction of physical hardware, and the brown part is the abstraction of software. The GEM structure is: drm_gem_object, and the rest are located in the structure drm_mode_object.
PS: drm_panel does not belong to the object category, it is just a collection of callback functions to reduce the coupling between the LCD driver and the encoder driver.
Figure 2.1 Introduction of DRM core components
2.2 How DRM abstract hardware associates with DRM Object
DRM objects are not difficult to understand. The important thing is how to associate the actual hardware with these objects. The following will take the MIPI DSI interface as an example to introduce the correspondence between software architecture and DRM objects.
Figure 2.2 Typical hardware connection diagram of MIPI DSI interface
Figure 2.3 Correspondence between hardware and DRM Objects
Among them, the component description:
3. Simple example of DRM
The DRM code is very large, and the logic of the graphics card is also very complex. When learning the DRM architecture, it is necessary to understand the DRM process through practice to achieve twice the result with half the effort.
The following will analyze the process of the DRM architecture with the mode setting case. The main process of modeset is as follows:
Figure 3.1 DRM Modeset process overview
3.1 Open DRM device file
After the DRM framework is successfully loaded, a device file /dev/dri/card0 will be created, and the upper layer user application can obtain various operations of the graphics card through this file node.
3.2 Obtain graphics card resource handle
After opening the DRM device file, use the following function to obtain the resource handle of the graphics card, and then operate the graphics card resource.
3.3 Get connectorId
After getting drmModeRes, get its connection object.
3.4 Create FrameBuffer
After creating the FrameBuffer, map a piece of memory and fill the memory with pixel data.
3.5 Set Crtc mode
The FB is created successfully and cleared to 0. You can fill it with any data, and after setting the CRTC, the content of the FB can be displayed on the screen.
CRTC mode setting function: drmModeSetCrtc(), the parameters are: fd, crtc handle, FB handle, X\Y coordinates, etc.
3.6 Resource cleanup (not required)
After the display is completed, the GUI will continue to run, and generally there is no need to implement resource cleanup.
chapter summary
This article introduces the development history, driver framework and simple examples of the DRM architecture. Requirements to sort out the code process, and subsequent chapters will also explain this part.
In addition, the DRM architecture conforms to the increasingly powerful modern display devices, but there are still many old devices and software that need FB support. In the current DRM framework, there will be codes that simulate FB devices. See drivers/gpu/drm/xxx/drv The .c file will appear in the device directory: /dev/fb0.
Reference
1.https://www.kernel.org/doc/html/latest/gpu/index.html
Linux GPU Driver Developer’s Guide
2. https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#kms-properties
Kernel Mode Setting (KMS)
Long press to follow Kernel Craftsman WeChat
Linux Kernel Black Technology | Technical Articles | Featured Tutorials