1、课程导论：为什么需要从FB迁移到DRM？DRM相比FB的优势与挑战。
1.1 背景：Linux显示子系统的演进
在早期的Linux内核中，Framebuffer (FB) 是标准的显示驱动框架。它提供了一个简单的内存映射接口，用户空间通过 /dev/fb0 设备节点直接操作显存。然而，随着硬件复杂度的提升（GPU、显示控制器、硬件合成器、多图层、高分辨率、高刷新率），Framebuffer 的局限性日益凸显。
DRM (Direct Rendering Manager) 自 Linux 2.6 时代开始引入，经过多年发展，已成为现代 Linux 显示驱动的标准框架。它统一管理显示控制器、GPU、硬件合成、模式设置、内存管理和同步，并提供了更安全、更高效的用户空间接口。
核心观点： 从 FB 到 DRM 的迁移，本质上是 Linux 显示子系统从“简单帧缓存”向“现代图形栈”的架构升级。这不仅是接口的替换，更是显示驱动设计理念的全面革新。
1.2 Framebuffer 的局限性
Framebuffer 框架在设计之初主要面向简单的嵌入式设备，其核心缺陷包括：
- 单缓冲/双缓冲限制： 缺乏对多图层（Plane）和硬件合成（Hardware Composition）的原生支持，所有合成必须在用户空间或CPU完成。
- 模式设置不安全： 用户空间直接操作寄存器或通过
FBIO_SET_VAR设置显示模式，缺乏原子性（Atomic）和校验机制，容易导致屏幕撕裂（Tearing）或配置冲突。 - 缺乏同步机制： 没有内置的 VBlank 同步或 Fence 机制，多进程并发访问时容易出现竞争条件。
- GPU 集成度低： 无法有效管理 GPU 的显存分配、命令提交和上下文切换，导致 3D 加速和视频编解码难以与显示输出协同。
- 设备节点单一： 每个显示设备只有一个
/dev/fbX节点，无法区分不同的显示控制器、图层或 CRTC。
嵌入式场景的痛点： 在 i.MX6、Rockchip RK3288 等 SoC 上，Framebuffer 驱动往往需要大量平台特定的 hack 代码来实现多图层叠加，且无法利用硬件的旋转、缩放和合成能力，导致功耗和性能双双受限。
1.3 DRM 的核心优势
DRM 框架通过引入 CRTC、Encoder、Connector、Plane、Framebuffer 等抽象对象，构建了一个完整且可扩展的显示模型。其核心优势如下表所示：
| 对比维度 | Framebuffer (FB) | DRM |
|---|---|---|
| 架构模型 | 单一帧缓存，无硬件抽象 | CRTC + Encoder + Connector + Plane 分层模型 |
| 多图层支持 | 无原生支持，需软件合成 | 原生支持硬件 Plane，可独立配置每个图层的格式、位置、透明度 |
| 模式设置 | 非原子性，易撕裂 | 原子模式设置 (Atomic Modeset)，一次性提交所有配置，保证一致性 |
| 同步机制 | 无标准同步接口 | VBlank 事件、Fence、DMA-BUF 同步 |
| GPU 集成 | 无，需额外驱动 | 原生集成 GEM (Graphics Execution Manager) 和 KMS (Kernel Mode Setting) |
| 用户空间接口 | ioctl 直接操作，不安全 |
drmMode* 系列 API，权限分离，安全校验 |
| 多显示器支持 | 困难，需多个 FB 设备 | 原生支持，一个 DRM 设备可管理多个 Connector 和 CRTC |
| 电源管理 | 基本无 | DPMS、自刷新 (Self-Refresh)、帧缓冲压缩 (FBC) |
1.4 DRM 架构概览（内联 SVG）
下图展示了 DRM 框架的核心组件及其关系。用户空间通过 /dev/dri/card0 与内核交互，内核中的 DRM Core 管理所有显示资源。
1.5 迁移面临的挑战
尽管 DRM 优势明显，但从 FB 迁移到 DRM 并非简单的接口替换，实际工程中会遇到以下挑战：
- 驱动重写成本高： FB 驱动通常直接操作寄存器，而 DRM 驱动需要实现
struct drm_crtc_helper_funcs、struct drm_plane_helper_funcs等一系列回调，代码结构完全不同。 - 硬件兼容性要求： 老旧 SoC 的显示控制器可能不支持 DRM 要求的原子模式设置或硬件 Plane，需要模拟或降级。
- 用户空间适配： 原有的基于
fbdev的应用程序（如 Qt 的 LinuxFB 后端、DirectFB）需要迁移到drm或gbm后端。 - 调试复杂度增加： DRM 的原子提交、Fence 同步、DMA-BUF 共享等机制引入的并发问题比 FB 更难定位。
- 内核版本依赖： 部分 DRM 特性（如
drm_bridge、drm_panel）需要较新的内核版本，对长期维护的 BSP 不友好。
常见陷阱： 在迁移过程中，不要试图在 DRM 驱动中保留 FB 的 ioctl 处理逻辑。DRM 框架要求驱动遵循其生命周期管理，混合使用两种模式会导致资源泄漏和状态不一致。正确的做法是：通过
drm_fbdev_generic_setup() 提供兼容的 fbdev 接口，但核心逻辑完全基于 DRM。
1.6 迁移决策矩阵
以下表格帮助团队快速评估是否需要进行迁移：
| 评估维度 | 建议保留 FB | 建议迁移到 DRM |
|---|---|---|
| 硬件复杂度 | 单图层、固定分辨率、无 GPU | 多图层、多显示器、GPU 加速 |
| 显示需求 | 静态 UI、文本终端 | 视频播放、3D 渲染、高帧率游戏 |
| 软件栈 | 裸机或轻量级 RTOS 风格 | Linux 桌面、Wayland/Weston、Android |
| 维护周期 | 短期产品，不升级内核 | 长期维护，需跟随主线内核 |
| 团队能力 | 嵌入式驱动经验为主 | 有 GPU 或图形栈开发经验 |
1.7 小结
从 Framebuffer 到 DRM 的迁移，是 Linux 显示驱动现代化的必然趋势。DRM 提供了更强大的硬件抽象、更安全的模式设置、更高效的同步机制和更完善的 GPU 集成能力。虽然迁移过程存在驱动重写、用户空间适配和调试复杂度等挑战，但对于需要多图层合成、硬件加速和长期维护的嵌入式产品而言，这是一项值得投入的基础架构升级。