1. 显示子系统概述：Linux 显示架构演进历史

Linux 显示子系统在过去二十多年中经历了从简单到复杂、从封闭到开放的深刻变革。早期内核仅提供最基本的帧缓冲抽象（fbdev），随着 GPU 硬件复杂化、显示管线多样化以及用户空间对合成器（如 Wayland）的需求，内核社区逐步演进到以 DRM（Direct Rendering Manager）和 KMS（Kernel Mode Setting）为核心的现代显示架构。本章从历史演进、核心概念对比两个维度，帮助读者建立完整的显示子系统知识图谱。

1.1 Linux 显示架构演进时间线

下表梳理了从 Linux 2.2 时代到当前 6.x 内核的关键里程碑：

1.2 fbdev 与 DRM/KMS 基本概念对比

fbdev（Frame Buffer Device）和 DRM/KMS（Direct Rendering Manager / Kernel Mode Setting）代表了两种截然不同的显示控制哲学。下面从架构层次、API 设计、硬件抽象、内存管理、模式设置、多图层支持六个维度进行对比：

1.3 架构演进核心驱动力

为什么 Linux 社区要投入巨大精力从 fbdev 迁移到 DRM/KMS？以下三个驱动力最为关键：

• 硬件复杂度爆炸： 现代 SoC 显示子系统包含多个显示控制器、DSI/HDMI/DP 接口、写回通道（writeback）、硬件光标、旋转/缩放引擎。fbdev 的单一帧缓冲模型无法表达这些硬件能力。
• 无撕裂与低延迟需求： 用户空间合成器（如 Weston、Mutter）需要内核提供 VBlank 同步、Page Flip、Atomic Commit 等机制，确保每一帧切换不产生撕裂（tearing）。fbdev 的 PAN_DISPLAY 接口无法保证原子性。
• 内存共享与零拷贝： DRM 的 GEM 机制允许 GPU、显示控制器、视频编解码器共享同一块物理内存，避免数据拷贝。fbdev 的固定 DMA 缓冲区无法实现这种共享。

1.4 显示子系统软件架构总览

下面这张 SVG 架构图展示了从用户空间到硬件的完整显示软件栈，重点标出 fbdev 与 DRM/KMS 两条路径的差异：

1.5 关键概念速查表

为帮助读者快速建立概念映射，下面列出 DRM/KMS 四大核心对象及其与 fbdev 的对应关系：

1.6 迁移路径概览

从 fbdev 迁移到 DRM/KMS 通常遵循以下步骤，后续章节将逐一深入：

1. 理解硬件显示管线： 梳理 SoC 的 CRTC 数量、Encoder 类型、Connector 接口、Plane 能力。
2. 注册 DRM 驱动： 实现 drm_driver 结构体，调用 drm_dev_alloc / drm_dev_register。
3. 实现 KMS 对象： 创建 CRTC、Encoder、Connector、Plane，并实现对应的回调函数。
4. 实现 GEM 内存管理： 选择 GEM（简单场景）或 TTM（复杂 GPU），实现 dumb buffer 分配。
5. 实现 Atomic Commit： 支持 drm_atomic_state 提交，确保无撕裂切换。
6. 添加 fbdev 模拟层（可选）： 使用 drm_fb_helper 兼容旧应用，但仅作为过渡。
7. 用户空间适配： 修改应用或合成器，直接使用 DRM/KMS API。