1. 课程导入

在嵌入式、桌面与服务端场景中，Linux显示子系统承担着从应用绘图到屏幕像素点亮的完整链路。很多工程师第一次接触DRM/KMS时，容易把它理解成“一个显卡驱动”，结果在调试黑屏、撕裂、分辨率异常时无从下手。实际上，Linux显示子系统是一套分层、分角色的协作体系：上层是图形应用与合成器，中间是DRM/KMS框架与GPU驱动接口，下层是显示控制器、编码器、桥接芯片与物理面板。理解这套整体架构，是后续学习GPU驱动接口与硬件适配工程的前提。

一、整体架构：从应用帧到屏幕像素

Linux显示子系统的核心是DRM（Direct Rendering Manager）与KMS（Kernel Mode Setting）。DRM负责GPU命令提交、显存管理与渲染上下文；KMS负责显示管线配置，包括CRTC、Plane、Encoder、Connector等对象。应用通过EGL/OpenGL ES、Vulkan或Wayland协议提交渲染结果，合成器（如Weston、Mutter、KWin）把多个图层合成后交给KMS扫描输出。GPU驱动则位于内核态，向上提供DRM设备节点，向下操作具体GPU硬件。

下图展示了从用户空间到硬件面板的典型数据流与对象关系。可以看到，应用并不直接操作寄存器，而是通过标准接口逐层下沉，最终由显示控制器把帧缓冲内容扫描到物理接口。

二、核心概念：DRM、KMS与GPU驱动接口

要读懂上面的架构图，需要先建立几个核心概念。DRM是内核中管理GPU的框架，它把GPU抽象为设备节点，并提供内存管理、命令提交、同步等能力。KMS是DRM的显示部分，它把显示管线抽象为若干对象：CRTC负责扫描输出时序，Plane负责图层合成，Encoder负责把像素编码成HDMI/DP/MIPI等信号，Connector代表物理接口与面板连接状态。GPU驱动接口则是具体硬件驱动实现的回调集合，例如atomic commit、mode set、page flip等。

这些对象之间不是孤立的，而是通过属性（property）和原子提交（atomic commit）机制协同工作。应用或合成器通过libdrm发起一次atomic commit，内核DRM核心校验后调用具体GPU驱动的atomic_check与atomic_commit，最终由显示控制器硬件执行。理解这条调用链，才能在出现“提交成功但屏幕不亮”时快速定位是Plane配置错误、Connector未连接，还是PHY未初始化。

三、工程实践路线：从点亮到调优

本课程后续章节将围绕一条可落地的工程路线展开。建议按以下顺序推进，避免一开始就陷入寄存器细节：

1. 环境与工具准备：确认内核配置开启DRM、KMS、对应GPU驱动与面板驱动，准备modetest、kmscube、libdrm工具集。
2. 点亮第一帧：通过modetest枚举Connector与CRTC，设置标准分辨率，验证Framebuffer扫描输出。
3. 理解驱动接口：阅读GPU驱动的atomic_commit、prepare_fb、enable_vblank等回调，建立接口与硬件的映射。
4. 硬件适配：根据面板时序、MIPI DSI参数、背光与电源序列，调整设备树与驱动配置。
5. 问题定位与调优：使用drm debugfs、ftrace、示波器与EDID解析，排查黑屏、闪烁、撕裂与带宽不足。

下面是一段常用的环境检查命令，用于确认DRM设备与连接器状态：

# 查看 DRM 设备节点
ls -l /dev/dri/

# 枚举显示资源与连接器
modetest -M msm -c

# 查看当前 CRTC 与 Plane 状态
modetest -M msm -p

# 内核 DRM 调试信息
cat /sys/kernel/debug/dri/0/summary

四、案例场景与常见误区

一个典型场景是：开发板通过MIPI DSI连接LCD面板，系统启动后背光亮但屏幕无图像。初学者常直接怀疑GPU驱动，实际上更常见的原因是设备树中panel节点未正确描述时序，或DSI Host与Panel之间的lane数、时钟频率不匹配。此时应先用modetest确认Connector是否处于connected状态，再检查panel的prepare/enable回调是否被调用，最后用示波器测量DSI时钟与数据lane。

另一个常见误区是把“DRM驱动加载成功”等同于“显示正常”。驱动probe成功只说明设备注册完成，KMS管线是否配置、Connector是否检测到EDID、Plane是否绑定Framebuffer，都需要额外验证。下表列出了显示子系统调试中常见的现象与优先排查方向：