DRM/KMS 的定位与整体框架

一套像样的显示系统，做的事情绝不只是“把一块内存里的像素送到屏幕上”。它至少要同时处理下面几件事：

• 屏幕该跑什么分辨率、刷新率和时序；
• 一帧画面里的多个图层怎么裁剪、缩放、叠加；
• 像素流该走哪条物理输出链路；
• 内容切换时怎么避免撕裂、闪烁和半帧更新；
• 显存、DMA、中断、热插拔、事件这些资源怎么统一管理；
• 电源、时钟、复位、背光在什么时机打开和关闭。

早期 Linux 常见的是 fbdev 框架。它简单直接：内核注册 framebuffer，用户态往里写像素，显示控制器把这块内存读出来，屏幕就亮了。

这个框架的问题不在于“不能用”，而在于它抽象得太粗。它擅长回答“现在显示的是什么”，却不擅长回答这些更现代的问题：

• 多个图层如何独立更新；
• 一个输出口支持哪些模式；
• 模式切换时哪些状态必须一起生效；
• 页面切换应该卡在什么显示边界；
• 外挂 bridge 或 panel 什么时候上电、什么时候关背光。

现代显示硬件本身也不再是“一个控制器接一块屏”的简单结构。SoC 里往往有多个图层单元、多个显示控制器、多个输出口，链路中间还可能插着 bridge 芯片、SerDes、协议转换器。继续用一个“大 framebuffer 抽象”去兜这些事情，边界会越来越糊，驱动最后也会越来越难维护。

这就是 DRM/KMS 存在的背景。

• DRM（Direct Rendering Manager） ：直接渲染管理器，图形子系统里的通用框架，负责设备模型、对象管理、用户态接口、事件和缓冲区相关基础设施；
• KMS（Kernel Mode Setting） ： DRM 里专门处理显示模式设置和显示管线控制的部分。

这里顺手把三个常见术语拆开：

模式设置（Mode Setting）
配置一条显示链路的输出参数，比如分辨率、刷新率、像素时钟、同步脉冲和 blanking 时序。

页翻转（Page Flip）
把当前显示的 framebuffer 切到另一块 framebuffer。它关注的是“下一帧显示哪块缓冲区”，不一定涉及分辨率变化。

原子提交（Atomic Commit）
把一组显示状态变更打包成一次整体更新。驱动先检查是否合法，再在合适的时机一次性提交，要么全部生效，要么全部不生效。

从职责上看：

• mode setting 解决“怎么输出”；
• page flip 解决“显示哪一帧”；
• atomic commit 解决“怎么稳定地切换状态”。

接下来看一下整体链路：

这条链路就是后面所有章节的主线。前半段是“图像输入和混合”，后半段是“图像输出和显示”。