1. 课程导论与背景：为什么需要从 FBDEV 迁移到 KMS？
在嵌入式 Linux 图形显示领域，帧缓冲设备（FBDEV）曾是标准方案。然而，随着硬件合成、多图层叠加、高帧率显示和低功耗需求的增长，FBDEV 的架构瓶颈日益凸显。直接渲染管理器（DRM）及其内核模式设置（KMS）子系统作为现代替代方案，已成为主流嵌入式平台（如 i.MX8、RK3588、STM32MP2）的默认选择。本章将系统对比两者的核心差异，阐明迁移的必要性。
核心观点： FBDEV 是“软件直推”时代的产物，KMS 是“硬件协同”时代的基石。迁移不仅是接口更换，更是显示架构从“CPU 中心”向“GPU/Display Controller 中心”的范式转变。
1.1 FBDEV 的架构与局限性
FBDEV（/dev/fbX）通过 fb_ops 结构体向用户空间暴露帧缓冲区。应用通过 mmap 直接操作显存，驱动负责将缓冲区内容刷新到显示面板。这种设计在单任务、低分辨率场景下足够简单，但在现代嵌入式系统中暴露出四大核心缺陷。
历史背景： FBDEV 诞生于 2.2/2.4 内核时代，当时 GPU 和显示控制器功能单一，硬件合成几乎不存在。它被设计为“最小可行显示方案”，而非高性能图形栈。
FBDEV 四大局限性
- 单缓冲机制： 整个显示设备只有一个帧缓冲区。应用写入时若恰好被刷新，会产生撕裂（tearing）。虽然部分驱动支持
FBIOPAN_DISPLAY实现双缓冲，但缺乏标准化的同步机制。 - 无硬件合成： FBDEV 只能输出一个平面（plane）。所有 UI 元素（视频、相机预览、GPU 渲染）必须在用户空间通过 CPU 合成到一个缓冲区中，消耗大量 CPU/GPU 带宽和内存。
- 无 VSync 控制： 缺乏垂直同步（VBlank）事件通知。应用无法精确知道显示刷新何时完成，导致帧率不稳定、动画卡顿，且无法实现低延迟的逐帧渲染。
- 无原子配置： 修改分辨率、位深、刷新率等参数时，需要先关闭显示、修改寄存器、再重新开启，中间会出现黑屏或闪屏，无法实现无缝切换。
FBDEV 与 KMS 核心能力对比
| 对比维度 | FBDEV | DRM/KMS |
|---|---|---|
| 缓冲区模型 | 单/双缓冲（无标准同步） | 多缓冲 + Flip 队列 + VBlank 同步 |
| 硬件合成 | 不支持（需 CPU 合成） | 多平面（Overlay/Primary/Cursor）硬件合成 |
| VSync 控制 | 无标准接口 | DRM_IOCTL_WAIT_VBLANK / VBlank 事件 |
| 配置切换 | 非原子（黑屏/闪屏） | 原子操作（Atomic Modeset，无缝切换） |
| 多显示器 | 每个 /dev/fbX 独立，无关联 |
CRTC + Encoder + Connector 模型，原生多屏 |
| GPU 集成 | 需额外 GEM 层，耦合差 | 原生 GEM/DUMB 缓冲，与 GPU 驱动无缝协作 |
迁移陷阱： 部分老旧 BSP 仍默认使用 FBDEV 模拟层（
CONFIG_DRM_FBDEV_EMULATION）来兼容遗留应用。这仅作为过渡方案，性能与功能均远不及原生 KMS，不应作为长期产品方案。
1.2 KMS 的优势：多平面、原子操作与 VBlank 同步
DRM/KMS 将显示硬件抽象为四个核心对象：CRTC（显示控制器时序）、Plane（硬件图层）、Encoder（编码器）和 Connector（物理连接器）。这种分层模型使驱动能够充分利用现代显示控制器的硬件能力。
三大核心优势详解
- 多平面硬件合成： 支持 Primary（主层）、Overlay（覆盖层）和 Cursor（光标层）。每个平面拥有独立的帧缓冲和位置/缩放参数。GPU 渲染、视频解码、相机预览可分别输出到不同平面，由显示控制器直接合成，无需 CPU 参与。
- 原子操作（Atomic Modeset）： 通过
DRM_IOCTL_MODE_ATOMIC一次性提交所有平面、CRTC 和连接器的配置变更。内核会校验整个配置的有效性，并在下一个 VBlank 边界统一应用，彻底消除闪屏和撕裂。 - VBlank 同步与 Page Flip： 驱动通过
drm_crtc_vblank_get/put管理垂直消隐区间。应用可以注册 VBlank 事件，或使用DRM_IOCTL_MODE_PAGE_FLIP在 VBlank 期间切换缓冲区，实现 60fps 的平滑动画。
性能数据： 在 i.MX8M Plus 平台上，使用 KMS 多平面合成（GPU 层 + 视频层）相比 FBDEV 全 CPU 合成，GPU 负载降低约 40%，内存带宽节省约 30%，帧率稳定性提升至 99.9% 无丢帧。
1.3 FBDEV 到 KMS 的架构演进
下图展示了从 FBDEV 的“单线直推”架构到 KMS 的“分层协同”架构的演进路径。左侧 FBDEV 中，所有图形任务（GPU、视频、UI）最终由 CPU 合成到一个缓冲区；右侧 KMS 中，各组件独立输出到硬件平面，由 Display Controller 完成最终合成。
1.4 迁移决策：何时必须切换到 KMS？
并非所有场景都需要立即迁移。以下决策矩阵帮助判断迁移优先级：
| 应用场景 | 推荐方案 | 理由 |
|---|---|---|
| 单色/低分辨率 LCD（< 480x320） | FBDEV（保留） | 硬件不支持多平面，KMS 驱动复杂度收益低 |
| 简单 UI + 静态显示 | FBDEV 或 KMS 模拟层 | 无性能要求，迁移成本高于收益 |
| 视频播放 + GPU 渲染叠加 | 必须 KMS | 需要硬件合成避免 CPU 过载 |
| 多显示器（HDMI + LVDS + MIPI） | 必须 KMS | FBDEV 无法管理多显示拓扑 |
| 高帧率游戏/实时渲染（> 60fps） | 必须 KMS | 需要 VBlank 同步 + Page Flip 保证无撕裂 |
| 产品量产（Android/Yocto 现代 BSP） | 必须 KMS | 社区已停止 FBDEV 新功能开发，KMS 是唯一长期维护路径 |
内核配置提醒： 迁移到 KMS 后，务必在内核配置中关闭
CONFIG_FB（或仅保留 CONFIG_DRM_FBDEV_EMULATION 作为过渡），避免 FBDEV 与 DRM 驱动冲突导致显示异常。同时确保 CONFIG_DRM、CONFIG_DRM_KMS_HELPER 和对应平台驱动（如 CONFIG_DRM_IMX、CONFIG_DRM_ROCKCHIP）已启用。
1.5 本章小结
- FBDEV 的单缓冲、无硬件合成、无 VSync 控制三大缺陷使其无法满足现代嵌入式显示需求。
- KMS 通过多平面硬件合成、原子操作、VBlank 同步实现了高性能、低延迟、无撕裂的显示体验。
- 架构演进的核心是从“CPU 软件合成”转向“Display Controller 硬件合成”，释放系统资源。
- 迁移决策应基于场景：简单静态显示可保留 FBDEV，但涉及视频、GPU、多屏或高帧率场景必须切换到 KMS。