1. 显示子系统概述：Linux显示子系统发展历程，FrameBuffer与DRM的定位与关系
1.1 Linux显示子系统发展脉络
Linux显示子系统经历了从原始Framebuffer到DRM/KMS的演进。早期内核仅提供简单的Framebuffer设备，应用程序直接操作显存；随着GPU复杂化、多显示器、合成器（Compositor）需求爆发，DRM（Direct Rendering Manager）成为现代Linux图形栈的基石。
核心认知： Framebuffer是“画布”，DRM是“画布+画笔+调度器”。DRM并非完全替代Framebuffer，而是在其基础上增加了模式设置（KMS）、显存管理（GEM）、同步（Fence）等能力。
发展时间线
| 时期 | 内核版本 | 关键组件 | 典型应用 |
|---|---|---|---|
| 1990s末-2000s初 | 2.2 ~ 2.6 | fbdev (Framebuffer Device) | 控制台、X11 fbdev驱动 |
| 2008 | 2.6.26 | DRM核心 + i915驱动 | Intel集成显卡 |
| 2012 | 3.3 | KMS (Kernel Mode Setting) 成熟 | Wayland/Weston |
| 2015+ | 4.x ~ 6.x | DRM框架统一，atomic API | Android HWC、现代桌面 |
1.2 Framebuffer（fbdev）的定位与局限
Framebuffer是Linux最早的标准显示接口，提供/dev/fb0设备节点，用户态通过mmap直接映射显存并写入像素数据。
fbdev核心特点
- 简单直接：open → mmap → 写像素 → 显示
- 无模式设置：分辨率、刷新率由内核或启动参数固定
- 单缓冲/双缓冲：通过
FBIOPAN_DISPLAY切换显示起始地址 - 无GPU加速：所有渲染由CPU完成
fbdev的致命缺陷： 不支持多显示器独立配置、不支持硬件图层合成、不支持VSync精确同步、无法与现代GPU的复杂管线协作。在Android和现代桌面中，fbdev已被完全弃用。
fbdev典型数据流
1.3 DRM（Direct Rendering Manager）的定位与架构
DRM是Linux内核中负责图形显示和GPU管理的子系统。它提供统一抽象，让用户态（Mesa、Wayland、Xorg）能够安全、高效地访问GPU和显示硬件。
DRM核心组件
| 组件 | 功能 | 用户态接口 |
|---|---|---|
| KMS (Kernel Mode Setting) | 分辨率、刷新率、连接器、编码器、CRTC管理 | drmModeGetResources / drmModeSetCrtc |
| GEM (Graphics Execution Manager) | 显存分配、共享、Fence同步 | drmIoctl(DRM_IOCTL_GEM_CREATE) |
| Dumb Buffer | 简单帧缓冲（用于无GPU场景） | drmIoctl(DRM_IOCTL_MODE_CREATE_DUMB) |
| Atomic API | 原子提交多个属性变更，避免撕裂 | drmModeAtomicCommit |
DRM软件架构分层
1.4 FrameBuffer与DRM的定位与关系
两者并非完全对立，而是继承与扩展的关系。DRM保留了Framebuffer的概念（drm_framebuffer），但将其提升为KMS对象，支持多图层、多平面、硬件合成。
关键差异对比
| 维度 | Framebuffer (fbdev) | DRM (drm_framebuffer + KMS) |
|---|---|---|
| 设备节点 | /dev/fb0 |
/dev/dri/card0 |
| 模式设置 | 内核固定 / fbset |
用户态通过KMS动态设置 |
| 多显示器 | 不支持独立配置 | 每个CRTC独立配置 |
| 硬件图层 | 无 | 支持Plane（主层、光标层、覆盖层） |
| VSync同步 | 无 / 依赖fbdev事件 | Page Flip + Fence精确同步 |
| GPU加速 | 不支持 | 通过GEM/PRIME共享显存 |
| 现代桌面支持 | 已废弃 | Wayland/Xorg标准后端 |
fbdev → DRM迁移路径
- 识别硬件：确认GPU/显示控制器是否已有DRM驱动（i915, amdgpu, msm, vc4等）
- 内核配置：启用
CONFIG_DRM、CONFIG_DRM_KMS_HELPER，关闭CONFIG_FB（或保留兼容层） - 用户态适配：将
/dev/fb0操作替换为libdrm+ KMS API - 合成器迁移：从fbdev直接渲染切换到Wayland/Weston或DRM leas
- 验证：使用
modetest、kmscube、drm_info测试
迁移建议： 对于嵌入式设备（如i.MX、Rockchip），如果GPU较弱，可以使用DRM的Dumb Buffer + KMS实现类似fbdev的简单显示，但获得多图层和VSync能力。这是“最小迁移路径”。
1.5 现代Linux显示栈全景
理解DRM在整个图形栈中的位置，有助于把握迁移的上下游依赖。
1.6 本章小结
- Framebuffer是Linux显示子系统的起点，适合简单场景，但已无法满足现代图形需求。
- DRM是当前标准，提供KMS、GEM、Atomic等完整能力，支持多显示器、硬件合成、VSync同步。
- 迁移的核心是从
/dev/fb0+ 直接显存操作，转向/dev/dri/card0+ libdrm API + KMS对象管理。 - 理解DRM架构分层（用户态→DRM Core→驱动→硬件）是后续章节实战的基础。