摘要
Android/Linux 显示体系里，DRM 不是某个单点模块，DRM 是 Linux 显示体系的核心框架。它统一管理 CRTC、Encoder、Connector、Plane、内存与同步，把上层图层安全提交给显示硬件；是在内核中负责显示资源管理、模式设置、图层提交和同步调度的核心框架。理解 DRM，是从“会调屏”走向“能定位黑屏、花屏、闪屏和图层异常问题”的关键一步。
前言
很多人刚接触显示驱动时，会把 DRM 理解成一个“屏幕驱动”。
其实不是。
在我理解看来DRM 更像是内核显示子系统的“基础设施”：它统一管理显卡、显示控制器、图层、连接器、内存和同步机制。Panel、MIPI、HWC 这些模块，最终都要挂到这套框架上工作。
1. DRM 到底解决了什么问题？
在 DRM 出现之前，Linux 显示路径比较分散，不同硬件各自管理显示资源，容易出现几个问题：
- 多个程序同时申请显示资源，谁都可以抢屏幕
- 图层叠加、模式切换没有统一协调
- 内存管理、同步机制不统一
- 用户态和内核态接口混乱
DRM 的目标，就是把这些能力统一起来：把显示资源抽象成统一模型，让用户态按规则申请、配置和提交。
它解决的不是“屏幕怎么亮”这一件事，而是：
- 谁可以访问显示设备
- 怎么设置显示模式
- 怎么提交图层
- 怎么分配和共享图形内存
- 怎么同步一帧画面的完成时机,时机很关键,时机不对送来图也不会正常显示.
2. DRM 在显示链路中的位置
回顾第1篇的链路：
App → SurfaceFlinger → HWC → Gralloc → DRM → Panel / MIPI → 屏幕
DRM 位于图形链路的内核入口，是用户态和显示硬件之间的桥梁。
可以把它理解成三层：
第一层：**user space interface**
App、SurfaceFlinger、HWC 通过 libdrm 或框架接口访问 DRM。
第二层：DRM 核心框架
内核里的 DRM 子系统负责：
- 设备初始化
- 资源管理
- 模式设置
- 属性解析
- 提交调度
- 同步处理
第三层：硬件驱动
具体芯片的 CRTC、Encoder、Connector、Plane、Panel、MIPI 驱动，按照 DRM 框架实现硬件操作。
3. DRM 最核心的几个概念
这几个概念需要理解记忆,甚至背诵，以后看日志、看驱动代码必须认识。在MTK等平台driver代码里，专门有对应的驱动文件。
CRTC
CRTC 可以理解为“显示控制器”。
它负责把一帧数据扫描出来，按照一定时序送到显示接口。
可以简单记：
CRTC 是真正产生显示时序、扫描帧数据的地方。
Encoder
Encoder 负责把 CRTC 输出的画面数据，转换成适合当前接口传输的格式或协议。
比如：
- 转换成 MIPI-DSI 流
- 转换成 HDMI 信号
- 转换成 DP 信号
可以理解为：
Encoder 是数据传输格式的转换器。
Connector
Connector 代表一个可见的显示输出接口。
比如：
- MIPI DSI接口
- HDMI 接口
- DP 接口
- 外接显示屏
用户看到的“某个屏幕已连接”，在 DRM 里通常对应一个 Connector。
Plane
Plane 是图层。
Android 里每个窗口（比如桌面和大家喜欢用的悬浮窗）、状态栏、视频层，都可能对应一个或多个 Plane（当前界面具体几个layer，需要dumpsys SurfaceFlinger确认）。
DRM 允许硬件把多个 Plane 叠加起来显示。
所以 Plane 的关键作用是：支持多图层硬件叠加。**（手机SOC硬件基本是会支持4层，当然也得看具体平台）**
FB / Framebuffer
Framebuffer 是一帧画面的内存缓冲区。
上层把绘制好的 Buffer 交给 DRM，DRM 把它映射到 Framebuffer，再由 CRTC 扫描输出。
可以理解为：Framebuffer 就是当前要显示的那帧数据。
4. DRM 提交一帧的大致过程
app要显示一帧，通常不是简单“写一下显存”，而是一个完整提交过程。
大致步骤：
- 准备图形 Buffer
- 用户态设置显示属性
- 检查配置是否合法
- commit到内核
- DRM 完成模式设置或更新
- 等待present fence，等画面真正显示完成
- 释放旧 Buffer
这里面最关键的一步，是“commit”。
DRM 不是改完寄存器立刻显示，而是把一次更新打包提交，由框架统一调度，通过fence来实现同步，后续章节再详细讨论。
5. 为什么现在强调 DRM Atomic？
Atomic 是 DRM 的重要改进。
它的核心思想是：把一次显示更新的所有配置，当成一个完整事务检查后再提交。
这有几个好处：
- 多个图层、模式、属性可以一起更新
- 配置不合法时，可以提前拒绝
- 减少中间状态错乱
- 更适合 Android 这种复杂合成场景
所以你会经常看到这些关键词：
- atomic_check
- atomic_commit
- state
- properties
它们本质上都围绕“原子提交”展开。
6. DRM 和 HWC 是什么关系？
这是很多人最容易混淆的地方。
可以这样理解：
- HWC：Android 用户态的硬件合成器，决定哪些图层走硬件合成
- DRM：Linux 内核里的显示框架，负责把最终图层提交给硬件
HWC 更像“策略选择器”，DRM 更像“执行入口”。
HWC 告诉系统：这几个图层可以硬件叠加。
然后由 DRM 完成真正的图层配置和提交。
7. 从调试角度看，DRM 为什么重要？
显示问题不一定都出在 DRM，但很多问题最终都会在 DRM 层留下痕迹。
遇到这些问题时，DRM 是关键排查点：
- 黑屏
- 花屏
- 闪屏
- 图层错位
- 模式切换失败
- 帧率异常
- 休眠唤醒异常
- Buffer 显示异常
因为 DRM 连接了：
- 上层 Buffer
- 图层配置
- 显示模式
- 同步机制
- 硬件寄存器
所以它是显示问题的“必经之路”。
8. 初学者怎么学 DRM？
建议按这个顺序来：
第一步：先看概念
搞懂 CRTC、Encoder、Connector、Plane、Framebuffer。
第二步：看日志
用 modetest、drm_info 看系统里有哪些显示资源。
第三步：看驱动结构
不必一开始啃完整源码，先看驱动里这几个部分：
- 初始化
- 模式设置
- 图层更新
- 电源管理
- 中断处理
第四步：再看 Atomic
理解 Atomic 前，先理解普通提交模型。后续章节再详细讨论。
结语
DRM 不是单一功能模块，而是 Linux 显示体系的骨架。
你可以暂时不深究每一个源码细节，但最好先建立这个认知：
DRM 负责统一管理显示资源，把上层图层和配置，安全、有序地提交给显示硬件。
以后遇到显示问题，不要只怀疑屏幕或 MIPI，也记得往 DRM 这条链路上看。
