1. KMS 概述：定义、作用与历史背景
1.1 KMS 的定义
KMS（Kernel Mode Setting） 是 Linux 内核中负责显示模式设置与管理的子系统。它将显示控制器的模式配置（分辨率、刷新率、像素格式、扫描时序等）从用户空间（X Server、Wayland Compositor）移入内核空间，由内核直接管理显示硬件。
KMS 是 DRM（Direct Rendering Manager） 框架的核心组成部分，提供以下关键能力：
- 模式设置（Mode Setting）：配置显示控制器的时序参数、分辨率、色彩深度。
- 帧缓冲管理（Framebuffer Management）：分配和管理显存中的帧缓冲对象。
- 显示平面（Plane）：管理硬件叠加层，支持合成多个图像源。
- 连接器与编码器（Connector & Encoder）：管理物理显示接口（HDMI、DP、VGA）和信号编码。
- CRTC（Cathode Ray Tube Controller）：抽象显示控制器核心，控制扫描输出时序。
核心概念： KMS 将显示模式设置从用户空间特权操作转变为内核管理的系统调用（
drmModeSetCrtc、drmModeAddFB 等），消除了用户空间直接操作硬件的安全风险与竞态条件。
1.2 KMS 的作用
KMS 在 Linux 图形栈中承担承上启下的关键角色，其作用体现在以下维度：
| 维度 | 作用描述 | 受益方 |
|---|---|---|
| 安全性 | 将显示硬件操作限制在内核空间，用户空间通过 DRM 文件描述符进行受控访问 | 系统安全、多用户环境 |
| 稳定性 | 统一管理模式切换，避免用户空间崩溃后显示器进入不可恢复状态 | 桌面环境、嵌入式系统 |
| 性能 | 减少用户空间与内核空间的上下文切换，支持原子模式设置（Atomic Modeset） | 游戏、VR、实时渲染 |
| 兼容性 | 提供统一的 API（DRM/KMS），屏蔽不同 GPU 厂商的硬件差异 | 驱动开发、显示服务器 |
| 电源管理 | 支持 DPMS（Display Power Management Signaling）和帧缓冲压缩 | 笔记本、移动设备 |
1.3 历史背景
KMS 的诞生源于 Linux 图形栈长期存在的架构问题。以下时间线梳理了关键演进节点：
- 2000 年代初期：用户空间模式设置（UMS）时代
- X Server 通过
ioctl直接操作显卡寄存器进行模式设置。 - 问题：X Server 崩溃后显示器黑屏、多用户切换困难、安全漏洞频发。
- X Server 通过
- 2008 年：Intel 首次提出 KMS
- Intel 的 Jesse Barnes 和 Keith Packard 在 Linux 内核邮件列表中提出将模式设置移入内核。
- 初始实现基于 DRM 框架，仅支持 Intel 集成显卡。
- 2009 年：KMS 合入 Linux 2.6.29
- DRM/KMS 作为实验性功能合入主线内核。
- 同期，AMD（Radeon）和 NVIDIA（nouveau）开始跟进。
- 2012 年：Atomic Modeset 设计启动
- 为解决多对象配置的竞态问题，DRM 社区提出原子模式设置。
- 2014 年 Linux 3.17 合入 Atomic Modeset 核心框架。
- 2016 年至今：KMS 成为标准
- 所有主流 GPU 驱动（Intel、AMD、NVIDIA、Qualcomm、ARM Mali）均支持 KMS。
- Wayland 和 X Server（通过 modesetting 驱动）完全基于 KMS。
关键转折： 2008 年 Intel 的 KMS 实现不仅解决了稳定性问题，还催生了 DRM 框架的标准化。如今，KMS 是 Linux 显示子系统的基石，任何显示控制器驱动适配都必须遵循 KMS 的组件模型。
1.4 KMS 在 DRM 框架中的位置
KMS 是 DRM 框架的两大核心子系统之一（另一个是 GEM，Graphics Execution Manager）。以下 SVG 图展示了 KMS 在 Linux 图形栈中的层级关系：
1.5 KMS 的核心组件模型
KMS 将显示硬件抽象为以下对象模型，驱动适配时必须实现这些对象的回调函数：
| 组件 | 内核结构体 | 职责 | 关键回调 |
|---|---|---|---|
| CRTC | drm_crtc |
控制扫描时序、像素时钟、帧同步信号 | mode_set, enable, disable |
| Plane | drm_plane |
管理硬件叠加层，支持缩放、旋转、色彩转换 | update_plane, disable_plane |
| Encoder | drm_encoder |
将 CRTC 输出的像素数据编码为特定接口信号 | mode_fixup, prepare, commit |
| Connector | drm_connector |
检测物理连接状态、读取 EDID、提供可用模式列表 | get_modes, detect, force |
| Framebuffer | drm_framebuffer |
封装显存中的像素缓冲区，包含格式、尺寸、步幅信息 | create_handle, destroy |
驱动适配要点： 显示控制器驱动必须为上述每个组件实现对应的
drm_*_funcs 回调结构体，并在 bind 函数中通过 drm_universal_plane_init、drm_crtc_init_with_planes 等 API 注册到 DRM 核心。任何组件的缺失或回调不完整都会导致 KMS 功能异常。
1.6 KMS 与用户空间模式设置（UMS）的对比
下表从多个维度对比 KMS 与传统 UMS 的差异，帮助理解 KMS 的设计优势：
| 对比维度 | KMS（内核模式设置） | UMS（用户空间模式设置） |
|---|---|---|
| 模式设置位置 | 内核空间，通过 DRM ioctl 调用 | 用户空间，X Server 直接操作寄存器 |
| 崩溃恢复 | 内核保持显示状态，用户空间可重启 | X Server 崩溃后显示器进入未知状态 |
| 多会话支持 | 原生支持 VT 切换、多用户并发 | 需要额外机制（如 VTSwitch） |
| 安全模型 | 通过文件权限和 DRM 主/从节点控制 | 依赖用户空间特权进程 |
| 原子操作 | 支持原子模式设置，无撕裂切换 | 不支持，模式切换存在中间状态 |
| 电源管理 | 集成内核 PM 框架，支持挂起/恢复 | 需要用户空间自行处理 |
| 驱动复杂度 | 驱动需实现 KMS 回调，但框架提供通用逻辑 | 驱动需暴露大量寄存器接口给用户空间 |