Linux DRM(二) --Xorg/DRM

了解xorg

1.前言

GUI作为人机交互的一种方式，通过其承载的大量信息提高了信息交流的效率。这里我们不介绍鼠标、键盘等输入设备，只介绍输出显示这一子模块。生活中大家最常见的图形化界面估计就是图像化界面的桌面环境，即窗口系统。

窗口系统一般都具备以下基本功能：

通过WIMO（Window-视窗、Icon-图标、Menu-选单、Pointer-指标）4个基本元素来实现人机交互；
上述的4个基本元素都能通过第三方的程序来扩展（也就是安装新程序）；

在实现方式上，大部分Linux下的窗口系统都是通过X来响应不同的交互请求及输出到显示器上。因此，整个应用层的GUI结构如下：
在这里插入图片描述
因此，在应用层面上，GUI系统的核心部分是X，X的总体功能一句话描述如下：通过指定的协议接受本地或远程的鼠标、键盘需求，并切输出相应的窗口画面到显示设备上。细分来讲，X主要由以下4个组件构成：

X server：负责软硬件的管理，将输入的软硬件事件通过一定协议转发给X client，将输出的图形绘制在屏幕上。包括键盘、鼠标、手写板、显示器（monitor）、屏幕分辨率与色彩深度、显卡（包含驱动程序）与显示的字体等等，都是 X Server 管理的。
X client：每个需要涉及到GUI的App，可以实例化为一个X client，X client主要是响应X server分发下来的事件，通过处理后，将待绘制的图像回传给X Server；
X window manager：X window manager作为一个特殊的X client，主要负责为X server管理多个X client（一个具体的例子就是对虚拟桌面的管理），起着视窗管理员的角色。常见的X window manager如下:
- GNOME (GNU Network Object Model Environment);
- KDE (K Desktop Enviroment)
- TWM (Tab Window Manager)
- XFCE (XForms Common Environment)
- Display manager：提供登陆许可环境以获得X Window的控制；

1.1.The X Window configuration file

In the early days of X, configuring a display meant having extensive knowledge of the display’s capabilities and the ability to express information about not only resolution, but also horizontal and vertical sync values, color depth, and so on. Since the advent of the Video Electronics Standards Association (VESA) and the Display Data Channel (DDC) protocols that allow a display to communicate these capabilities to a graphics card and thus to a computer, configuration has become much more automatic. This is fortunate as we now expect to be able to take our notebook anywhere and just plug in an available external monitor or projector.

Configuring your mouse, trackball, or keyboard has also become more automatic. Generally, you just plug in the device, often through a USB connection and it works.

However, as with most things in Linux, there is an underlying configuration mechanism that you can use. In fact, the Xorg implementation of X obtains configuration information from several sources. The main configuration file is xorg.conf, along with files included from the xorg.conf.d directory. These are usually located in /etc/X11. Additional configuration can come from command-line options, environment variables, auto-detection, and fallback defaults.

Xorg uses a configuration file called xorg.conf and files ending in the suffix .conf from the directory xorg.conf.d for its initial setup. The xorg.conf configuration file is searched for in the following places when the server is started as a normal user:

/etc/X11/<cmdline>
/usr/etc/X11/<cmdline>
/etc/X11/$XORGCONFIG
/usr/etc/X11/$XORGCONFIG
/etc/X11/xorg.conf
/etc/xorg.conf
/usr/etc/X11/xorg.conf.<hostname>
/usr/etc/X11/xorg.conf
/usr/lib/X11/xorg.conf.<hostname>
/usr/lib/X11/xorg.conf

The xorg.conf configuration file and the files in the xorg.conf.d directory are organized into sections which may be specified in any order. The general section format is shown in Listing 1.

Listing 1. Section layout in xorg.confSection  "SectionName"SectionEntry...EndSection

You can include the following sections:

Files – File pathnames
ServerFlags – Server flags
Module – Dynamic module loading
Extensions – Extension enabling
InputDevice – Input device description
InputClass – Input class description
OutputClass – Output class description
Device – Graphics device description
VideoAdaptor – Xv video adaptor description
Monitor – Monitor description
Modes – Video modes descriptions
Screen – Screen configuration
ServerLayout – Overall layout
DRI – DRI-specific configuration
Vendor – Vendor-specific configuration

Note:
Read the man or info pages for xorg.conf to find out more about the various sections of the files. Man pages for Xserver and Xorg provide additional information. (man xorg.conf)

The X server supports two configuration directories.

The /usr/share/X11/xorg.conf.d/ provides separate configuration files from vendors or third-party packages; changes to files in this directory may be overwritten by settings specified in the /etc/X11/xorg.conf file.
The /etc/X11/xorg.conf.d/ directory stores user-specific configuration.

Note:
大部分Xorg的配置文件存储在 /etc/X11/xorg.conf.d/。每个文件的名字都是独一无二的并且以.conf为扩展名。 Xorg配置目录中的文件名会按字母顺序读取。例如，10-evdev.conf会在20-synaptics.conf之前被读取； a-evdev.conf 会在b-synaptics.conf之前被读取…… 此目录中的文件不需要编号,但是如果编号，那么会帮助他们有组织化。组织化有助于调试错误的配置文件。
uos@uos-PC:/usr/share/X11/xorg.conf.d$ ls
10-amdgpu.conf 10-quirks.conf 10-radeon.conf 10-zxgpu.conf 40-libinput.conf 70-wacom.conf

The directory /usr/lib/xorg/modules/ contains X server modules that can be loaded dynamically at runtime. By default, only some modules in /usr/lib/xorg/modules/ are automatically loaded by the X server.

uos@uos-PC:/usr/lib/xorg/modules/drivers$ ls -l
总用量 3380
-rw-r--r-- 1 root root  160896 1月  12 17:09 amdgpu_drv.so
-rw-r--r-- 1 root root   14504 1月  12 17:09 ati_drv.so
-rw-r--r-- 1 root root   27648 1月  12 17:09 fbdev_drv.so
-rw-r--r-- 1 root root 1702440 1月  12 17:09 intel_drv.so
-rw-r--r-- 1 root root  111168 1月  12 17:09 modesetting_drv.so
-rw-r--r-- 1 root root  225416 1月  12 17:09 nouveau_drv.so
-rw-r--r-- 1 root root  514368 1月  12 17:09 radeon_drv.so
-rw-r--r-- 1 root root   31784 1月  12 17:09 vesa_drv.so
-rw-r--r-- 1 root root  170296 1月  12 17:09 vmware_drv.so
-rw-r--r-- 1 root root  481616 1月  12 17:09 zx_drv.so

1.2.Section

The xorg.conf and xorg.conf.d files are composed of a number of sections which may be present in any order, or omitted to use default configuration values. Each section has the form:

Section "SectionName"
SectionEntry
...
EndSection

The section names are:

Files File pathnames
ServerFlags Server flags
Module Dynamic module loading
Extensions Extension enabling
InputDevice Input device description
InputClass Input class description
Device Graphics device description
VideoAdaptor Xv video adaptor description
Monitor Monitor description
Modes Video modes descriptions
Screen Screen configuration
ServerLayout Overall layout
DRI DRI−specific configuration
Vendor Vendor−specific configuration

1.2.1.DEVICE SECTION

The config file may have multiple Device sections. There must be at least one, for the video card being used.

Device sections have the following format:

Section "Device"
Identifier "name"
Driver "driver"
entries
...
EndSection

The Identifier and Driver entries are required in all Device sections. All other entries are optional.

The Identifier entry specifies the unique name for this graphics device.
The Driver entry specifies the name of the driver to use for this graphics device.

When using the loadable server, the driver module “driver” will be loaded for each active Device section. A Device section is considered active if it is referenced by an active Screen section.

1.2.2.OUTPUTCLASS SECTION

The config file may have multiple OutputClass sections. These sections are optional and are used to provide configuration for a class of output devices as they are automatically added. An output device can match more than one OutputClass section. Each class can override settings from a previous class, so it is best to arrange the sections with the most generic matches first.

OutputClass sections have the following format:

Section "OutputClass"Identifier  "name"entries...
EndSection

The Identifier entry is required in all OutputClass sections. All other entries are optional.The Identifier entry specifies the unique name for this output class. The Driver entry specifies the name of the driver to use for this output device. After all classes have been examined, the “outputdriver” module from the first Driver entry will be enabled when using the loadable server.

Note: What’s the difference between xorg’s OutputClass and Device sections?

The main difference is that Device sections are used for static configuration (e.g. “here’s the configuration for a specific piece of hardware”) while the *Class sections are used for dynamic configuration (e.g. "here’s the configuration for any device that has these properties).

https://www.reddit.com/r/linuxquestions/comments/iaz692/whats_the_difference_between_xorgs_outputclass/

1.3.生成xorg.conf

进入 multi-user.target

[root@localhost ~]# systemctl get-default
graphical.target//若需要設定預設的操作界面，例如將原本的圖形界面改為文字界面的操作方式時，可以使用如下的方式來處理：
[root@localhost ~]# systemctl set-default multi-user.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to/usr/lib/systemd/system/multi-user.target.

然后执行： Xorg -configure，可以生成 xorg.conf 模板:
执行后会在 /root/ 生成 xorg.conf.new 文件，然后你可以将它复制到 /etc/X11/xorg.conf。

Note:
$ systemctl get-default # 查看启动时的默认 Target
$ sudo systemctl set-default multi-user.target # 设置启动时的默认 Target
$ sudo systemctl isolate multi-user.target # 切换到后面接的模式

2.Linux GUI子系统构成及工作流程

从应用层深入到内核中去。暂不考虑在linux下的GUI，我们知道，单纯的显示图片的话，整个数据流的走向是这样的：
在这里插入图片描述

即按照一定时序时序，将图像信息从内存中输出到显示接口上。若在生成Frame buffer里面的图像数据时不仅通过软件memory处理，还用到了硬件加速的话，数据流则变为如下：

在这里插入图片描述
其中accelerate logic就是显卡部分（若是SOC的片内GPU模块，则是通过片内高速总线进行数据交互的，若若是独立显卡，一般是通过pci-e高速串行接口进行数据传输的）。把这个数据流走向放入Linux中，数据流和控制流都需要和用户层进行交互，也就是说，Linux下，必须得有相关的软件驱动给用户层提供相应的API。这也就是DRM（Direct Rendering Manager）和KMS（Kernel Mode Setting）的角色。

Linux提供由DRM+KMS构成的DRI（Direct Rendering Infrastructure）中：

DRM主要负责负责数据流，即通过软件或硬件，生成目标图像，存储在framebuffer中；
KMS主要负责控制流，即针对外置LCD以及指定的显示模式设置，将生成好了的frame数据信息送到响应display port上（VGA、HDMI等）；

Kernel将这两大快的基本API抽出来封装成libdrm供X使用，整个应用层+kernel相关的GUI结构如下图：

在这里插入图片描述

3.Direct Rendering Manager

The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display. DRM was first developed as the kernel-space component of the X Server Direct Rendering Infrastructure,[1] but since then it has been used by other graphic stack alternatives such as Wayland.

User-space programs can use the DRM API to command the GPU to do hardware-accelerated 3D rendering and video decoding, as well as GPGPU computing.1.DRM - Direct Rendering Manager

DRM是一个内核级的设备驱动，既可以编译到内核中也可以作为标准模块进行加载。DRM最初是在FreeBSD中出现的，后来被移植到Linux系统中，并成为Linux系统的标准部分。

DRM是Linux目前主流的图形显示框架，相比FB架构，DRM更能适应当前日益更新的显示硬件。比如FB原生不支持多层合成，不支持VSYNC，不支持DMA-BUF，不支持异步更新，不支持fence机制等等，而这些功能DRM原生都支持。同时DRM可以统一管理GPU和Display驱动，使得软件架构更为统一，方便管理和维护。

DRM从模块上划分，可以简单分为3部分：libdrm、KMS、GEM。
在这里插入图片描述

libdrm
对底层接口进行封装，向上层提供通用的API接口，主要是对各种IOCTL接口进行封装。
KMS
Kernel Mode Setting，所谓Mode setting，其实说白了就两件事：更新画面和设置显示参数。
更新画面：显示buffer的切换，多图层的合成方式，以及每个图层的显示位置。
设置显示参数：包括分辨率、刷新率、电源状态（休眠唤醒）等。
GEM
Graphic Execution Manager，主要负责显示buffer的分配和释放，也是GPU唯一用到DRM的地方

3.1.基本元素

DRM框架涉及到的元素很多，大致如下：

KMS：CRTC，ENCODER，CONNECTOR，PLANE，FB，VBLANK，property
GEM：DUMB、PRIME、fence

3.2.接口介绍

connector–>encoder–>crtc–>framebuffer的顺序倒过来介绍:

3.2.1.Connector

Connector是和显示器连接的物理接口，常见的有VGA/HDMI/DVI/DP等。以HDMI为例，HDMI的接口信号主要由以下几组信号组成：

1组TMDS clock：差分时钟用于同步信号驱动；
3组TMDS data：查分数据传输视频信号；
1组I2C：用于EDID的获取；
1组音频总线；

注：EDID全称是Extended Display Identification Data(扩展显示标识数据)，目的是让视频信号输出设备输出前获取到存储在显示器内部的相关参数，如支持的分辨率、帧率、图像格式：RGB等，因此，整个输出的控制参数是由以下几个部分综合决定的：
1.通过connector读出的显示器支持的参数；
2.内核静态配置或devicetree传入的参数；
3.用户空间输入的参数

HDMI类型的connector的任务就是输出显示器解码芯片所需的信号时序（主要是TMDS clock以及TMDS data）。

3.2.2.Encoder

Encoder就是将一定格式的图像信号（如RGB、YUV等）编码成connector需要输出的信号。以HDMI为例，帧/行同步/显示内容都是通过TMDS data的串行总线输出的，那么并行的时序按照HDMI的标准编码为串行顺序则是Encoder的任务。

3.2.3.CRTC

CRTC的任务是从Framebuffer中读出待显示的图像，并按照相应的格式输出给Encoder。

3.2.4.Planes

Plane其实就是图层，实际输出的图像往往由多个图层叠加而成，比如主图层，显示光标的图层，其中有些图层由硬件加速模块生成，本例中不涉及，因此所有plane的相关操作都由软件实现，不涉及到任何硬件结构。

3.2.5.Framebuffer

Framebuffer对应着存储空间中的图像数据，此处对应硬件为DDR。

在这里插入图片描述

refer to

https://www.x.org/wiki/
https://wiki.gentoo.org/wiki/Xorg/Guide/zh-cn
https://developer.ibm.com/tutorials/l-lpic1-106-1/
https://zhuanlan.zhihu.com/p/59784377
https://zhuanlan.zhihu.com/p/60504398
https://en.wikipedia.org/wiki/Direct_Rendering_Manager
https://dri.freedesktop.org/docs/drm/gpu/index.html
https://www.jianshu.com/p/50405e326127
https://blog.csdn.net/hexiaolong2009/article/details/83720940
https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/x-config.html
https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml
https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-x-server-configuration.html