音视频开发基础知识-drm简介
- 前言
- 一。DRM的基础概念
- 1. DRM是什么？
- 2. DRM的组成
- 2.1 libdrm
- 2.2 GEM
- 2.3 KMS
- 二。KMS各个元素详解
- 1. plane
- 1.1 定义：
- 1.2 类型
- 1.3 功能
- 1.4 使用：
- 1.5 注意：
- 2. property
- 2.1 定义和作用：
- 2.2 常用的property及含义
- 三。drm应用程序调用流程
- 1. 初始化：
- 1.1 打开设备
- 1.2 设置drm的flag：
- 1.3 获取crtc,encoder,connector,plane
- 2. 创建dumb空间并通过mmap映射到应用层
- 2.1 创建dumb buffer
- 2.2 通过mmap映射到应用层
- 3. 将相机数据传入前面mmap映射的地址中
- 4. 提交数据
- 5. 资源释放
- 总结：
- 参考资料
前言
最近工作上有些需求需要使用到drm中的plane，作为一名小菜鸟，在面对这个需求的时候，一堆问号又不由自主地从我的小脑瓜里面冒了出来。drm是什么？plane是什么？它们有什么用？它们有什么关系？它们要怎么用？所幸，万能的互联网存在各种知识，只需要我们花时间去寻找和学习，就能把各种各样的问题解决。
本文将会结合网上的资料和我自己的理解，来尝试回答以上的问题。
特别声明：
本文很大部分信息来自其他博文，具体的博文网址见文末的参考资料。
一。DRM的基础概念
1. DRM是什么？
DRM是Linux目前主流的图形显示框架，相比FB架构，DRM更能适应当前日益更新的显示硬件。比如FB原生不支持多层合成，不支持VSYNC，不支持DMA-BUF，不支持异步更新，不支持fence机制等等，而这些功能DRM原生都支持。同时DRM可以统一管理GPU和Display驱动，使得软件架构更为统一，方便管理和维护。
2. DRM的组成
DRM从模块上划分，可以简单分为3部分：libdrm、KMS、GEM。
其中KMS还包括：CRTC，ENCODER，CONNECTOR，PLANE，FB，VBLANK，property。
而GEM还包括：DUMB、PRIME、fence。
由于我目前需要了解的是plane属于KMS模块，我们将着重了解的是KMS。
2.1 libdrm
libdrm对底层接口进行封装，向上层提供通用的API接口，主要是对各种IOCTL接口进行封装。应用层可以直接使用libdrm中的接口来达到图像显示和图像处理等功能。
2.2 GEM
Graphic Execution Manager，主要负责显示buffer的分配和释放，也是GPU唯一用到DRM的地方。
属于GEM模块的几个专有名词的意义如下：
| 元素 | 说明 |
|---|---|
| DUMB | 只支持连续物理内存，基于kernel中通用CMA API实现，多用于小分辨率简单场景 |
| PRIME | 连续、非连续物理内存都支持，基于DMA-BUF机制，可以实现buffer共享，多用于大内存复杂场景 |
| fence | buffer同步机制，基于内核dma_fence机制实现，用于防止显示内容出现异步问题 |
2.3 KMS
Kernel Mode Setting，所谓Mode setting，其实说白了就两件事：
更新画面和设置显示参数。
更新画面：显示buffer的切换，多图层的合成方式，以及每个图层的显示位置。
设置显示参数：包括分辨率、刷新率、电源状态（休眠唤醒）等。
属于KMS的几个专有名词的意义如下：
| 元素 | 说明 |
|---|---|
| CRTC | 对显示buffer进行扫描，并产生时序信号的硬件模块，通常指Display Controller |
| ENCODER | 负责将CRTC输出的timing时序转换成外部设备所需要的信号的模块，如HDMI转换器或DSI Controller |
| CONNECTOR | 连接物理显示设备的连接器，如HDMI、DisplayPort、DSI总线，通常和Encoder驱动绑定在一起 |
| PLANE | 硬件图层，有的Display硬件支持多层合成显示，但所有的Display Controller至少要有1个plane |
| FB | Framebuffer，单个图层的显示内容，唯一一个和硬件无关的基本元素 |
| VBLANK | 软件和硬件的同步机制，RGB时序中的垂直消影区，软件通常使用硬件VSYNC来实现 |
| property | buffer同步机制，基于内核dma_fence机制实现，用于防止显示内容出现异步问题 |
它们之间的关系和作用如下图所示，值得注意的是与显示屏连接的是connector，而plane可以存在多个也可以同时使用多个plane来进行图像显示。
（图片来源：The DRM/KMS subsystem from a newbie’s point of view）
二。KMS各个元素详解
本文主要整理plane和property的内容，其余内容详见原博文。（文末有链接）
1. plane
1.1 定义：
Plane指的是Display Controller中用于多层合成的单个硬件图层模块。
Plane是连接FB与CRTC的纽带，是内存的搬运工。意思就是说，plane的作用是将帧缓存搬到CRTC中。
1.2 类型
| 类型 | 说明 |
|---|---|
| Cursor | 光标图层，一般用于PC系统，用于显示鼠标 |
| Overlay | 叠加图层，通常用于YUV格式的视频图层 |
| Primary | 主要图层，通常用于仅支持RGB格式的简单图层 |
其实随着现代半导体技术的飞速发展，
Overlay Plane和Primary Plane之间已经没有明显的界限了，许多芯片的图层处理能力已经非常强大，不仅仅可以处理简单的RGB格式，也可以处理YUV视频格式，甚至FBC压缩格式。针对这类硬件图层，它既可以是Overlay Plane，也可以是Primary Plane，至于驱动如何定义，就要看工程师的喜好了。
而对于一些早期处理能力比较弱的硬件，为了节约成本，每个图层支持的格式并不一样，比如将平常使用格式最多的RGB图层作为Primary Plane，而将平时用不多的YUV视频图层作为Overlay Plane，那么这个时候上层应用程序在使用这两种plane的时候就需要区别对待了。
1.3 功能
一个高级的Plane，通常具有如下功能：
| 功能 | 说明 |
|---|---|
| Crop | 裁剪，如上图 |
| Scaling | 缩放，放大或缩小 |
| Rotation | 旋转，90° 180° 270° X/Y镜像 |
| Z-Order | Z-顺序，调整当前层在总图层中的Z轴顺序 |
| Blending | 合成，pixel alpha / global alpha |
| Format | 颜色格式，ARGB888 XRGB888 YUV420 等 |
1.4 使用：
伪代码：
int main(void)
{...drmSetClientCap(fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);drmModeGetPlaneResources(fd);drmModeSetPlane(plane_id, crtc_id, fb_id, 0,crtc_x, crtc_y, crtc_w, crtc_h,src_x << 16, src_y << 16, src_w << 16, src_h << 16);...
}
（1）设置DRM_CLIENT_CAP_UNIVERSAL_PLANES：
drmSetClientCap(fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
//fd为前面打开的文字描述符
因为如果不设置DRM_CLIENT_CAP_UNIVERSAL_PLANES，
drmModeGetPlaneResources()就只会返回Overlay Plane，其他Plane都不会返回。而如果设置了，DRM驱动则会返回所有支持的Plane资源，包括cursor、overlay和primary。
（2）获取plane资源（主要需要获取所需的plane_id）：
drmModePlaneRes *plane_res;
uint32_t plane_id;
plane_res = drmModeGetPlaneResources(fd);
plane_id = plane_res->planes[0];
（3）实现裁剪、平移和放大的效果：drmModeSetPlane()drmModeSetPlane的详细定义
drmModeSetPlane(plane_id, crtc_id, fb_id, 0,crtc_x, crtc_y, crtc_w, crtc_h,src_x << 16, src_y << 16, src_w << 16, src_h << 16);
这个函数的参数含义如下：
1.5 注意：
（1）要与YUV/YCbCr图形格式中的plane区分开来：
DRM中的Plane和我们常说的YUV/YCbCr图形格式中的plane完全是两个不同的概念。YUV图形格式中的plane指的是图像数据在内存中的排列形式，一般Y通道占一段连续的内存块，UV通道占另一段连续的内存块，我们称之为YUV-2plane
(也叫YUV 2平面)，属于软件层面。而DRM中的Plane指的是Display
Controller中用于多层合成的单个硬件图层模块，属于硬件层面。二者概念上不要混淆。
（2）并不是所有的Display Controller都支持Plane，即使没有plane_id，屏幕也能正常显示。比如s3c2440这种骨灰级ARM9 SoC，它的LCDC就没有Plane的概念。但是DRM框架规定，任何一个CRTC，必须要有1个Primary Plane。 即使像S3C2440这种不带真实Plane硬件的Display Controller，我们也认为它的Primary Plane就是LCDC本身，因为它实现了从Framebuffer到CRTC的数据搬运工作，而这正是一个Plane最基本的功能。
2. property
2.1 定义和作用：
用来控制drm各个环节参数的全局属性，Property的结构简单概括主要由3部分组成：
name、id和value，不同的property控制不同的环节，也有不同的name、id和value。通过获取不同的property并进行相应的设置，便可以控制drm各个环节。
2.2 常用的property及含义
DRM应用程序进阶 （Property）
三。drm应用程序调用流程
注意：以下都是伪代码，实际函数的参数并不如下面代码所示
1. 初始化：
1.1 打开设备
open(/dev/dri/card0)
1.2 设置drm的flag：
drmSetClientCap(DRM_CLIENT_CAP_UNIVERSAL_PLANES)
drmSetClientCap(DRM_CLIENT_CAP_ATOMIC)
（1）为什么要设置 DRM_CLIENT_CAP_ATOMIC ？
凡是被
DRM_MODE_PROP_ATOMIC修饰过的property，只有在drm应用程序支持Atomic操作时才可见，否则该property对应用程序不可见。因此通过设置DRM_CLIENT_CAP_ATOMIC这个flag，来告知DRM驱动该应用程序支持Atomic操作。
（2）为什么要设置 DRM_CLIENT_CAP_UNIVERSAL_PLANES ？
因为如果不设置
DRM_CLIENT_CAP_UNIVERSAL_PLANES，drmModeGetPlaneResources()就只会返回Overlay Plane，其他Plane都不会返回。而如果设置了，DRM驱动则会返回所有支持的Plane资源，包括cursor、overlay和primary。
1.3 获取crtc,encoder,connector,plane
drmModeGetResources()
drmModeGetConnector() //found connector DSI
drmModeObjectGetProperties() //found connector dpms prop
drmModeGetEncoder() //found encoder DSI
drmModeGetCrtc() //found crtc that connect to DSI
drmGetPlaneByType(DRM_PLANE_TYPE_PRIMARY) //get PRIMARY/OVERLAY type drm plane info
drmModeObjectGetProperties(plane_id,DRM_MODE_OBJECT_PLANE) //get drm plane properties
drmModeGetProperty() //get drm info like crtc_id,fb_id and so on,they be used for commit
获取crtc,encoder,connector,plane的先后顺序为connector,encoder,crtc,plane，每个前者的结构中都有后者的id号，发现connector后可以用过其结构下的encoder_id找到与自己连接的encoder模块，同理直到找到从plane到connector的连接通路。
2. 创建dumb空间并通过mmap映射到应用层
2.1 创建dumb buffer
【什么是dumb buffer：关于 DRM 中 DUMB 和 PRIME 名字的由来】
drmIoctl(DRM_IOCTL_MODE_CREATE_DUMB)
2.2 通过mmap映射到应用层
【什么是mmap：【深入浅出Linux】关于mmap的解析】
drmIoctl(DRM_IOCTL_MODE_MAP_DUMB) //获取dumb buffer的映射偏移值
mmap() //通过mmap映射内核空间到应用层
3. 将相机数据传入前面mmap映射的地址中
drmPrimeHandleToFD(fd,handle,0,&fd2) //handle已和fd绑定,在此将fd2与handle绑定,即fd2同fd相同
drmModeAddFB2() //添加framebuffer
可以将相机数据从相机buf拷贝到mmap空间，但该方式效率太低，对于高帧率的应用场景可以使用DMA_BUF机制将相机数据buf和mmap空间建立连接，使数据通过dma通道直达mmap空间。
4. 提交数据
drmModeAtomicAlloc() //申请Atomic结构
drmModeAtomicAddProperty() //将前面获取的crtc_id,fb_id等参数都传入申请的Atomic结构中
drmModeAtomicCommit() //提交数据到display
【 Atomic Commit具体的用法见：DRM应用程序进阶 （atomic-plane）】
5. 资源释放
drmModeRmFB(fb_id) //删除drmModeAddFB2()添加的framebuffer，不然会造成shmem泄露
munmap() //释放mmap映射的内存
close() //关闭打开的drm句柄
总结：
以上便为应用程序调用libdrm的流程，其中的3和4在循环中，1和2只需要调用一次，但在某些场景中需要释放2中申请的资源，但1中初始化的不能释放；
该场景为：单一plane,crtc等，需要多次打开和关闭display，且系统中有多个功能块在使用drm中的一个或多个模块(比如视频编码用到encoder模块)，这样，若将1中初始化的资源释放掉，再次获取时可能会被其他进程占用导致无法获取，这种场景下就需要保留1中资源，但多次申请/是否2中资源。
但这样会引入一个问题：调用drmModeRmFB函数释放fb，但若释放了正在用于提交的fb，内核会将crtc关闭，导致vop数据传输通路断裂，而且没有framebuffer时Encoder也会被disable，此时再打开vop也无法获取Encoder，致使vop不通；虽然内核宏CONFIG_DRM_FBDEV_EMULATION使能时，在所有的drmfd关闭后fbdev会重新配置crtc，但由于其他进程也打开了drm，因此crtc不会再次被设置，除非重启程序。
解决这一问题的方法是：打开vop时调用drmModeSetCrtc函数手动设置crtc，即使无法找到Encoder，该函数也会使用一个默认的Encoder将crtc，encoder，connector三者建立连接，从而打通vop通路。
也就是说在以上的应用场景下即使内核默认使能了宏CONFIG_DRM_FBDEV_EMULATION，也需要调用到drmModeSetCrtc()函数，非以上场景可不用调用(对于Atomic模式来说)。
参考资料
- 特别推荐：DRM（Direct Rendering Manager）学习简介
- 特别推荐：linux drm原理及应用
- DRM应用程序进阶 （atomic-plane）
