1. 课程导论：为什么需要对比 fbdev 与 DRM？现代 Linux 显示栈的演进背景
在 Linux 显示子系统的历史长河中，帧缓冲（fbdev）与直接渲染管理器（DRM）是两代核心显示框架。理解它们之间的差异、演进逻辑与适用场景，是每一位内核显示驱动开发者、BSP 工程师与系统架构师的必修课。本章将从历史背景、技术痛点与生态变迁三个维度，剖析为什么我们需要进行这场选型对比。
1.1 从 fbdev 到 DRM：Linux 显示栈的两次跨越
Linux 显示栈的演进并非一蹴而就，而是经历了从“简单可用”到“复杂高效”的两次关键跨越。下表概括了三个主要阶段的核心特征：
| 阶段 | 核心框架 | 时间跨度 | 主要驱动模型 | 典型应用 |
|---|---|---|---|---|
| 早期探索 | fbdev | 1990s – 2000s | 单缓冲、固定模式 | 控制台、简单 GUI |
| 过渡期 | fbdev + DRI | 2000s – 2010s | 多缓冲、硬件加速初探 | X11 间接渲染 |
| 现代成熟 | DRM / KMS | 2010s – 至今 | 原子提交、显存管理、合成器 | Wayland、Android、嵌入式 GPU |
从表中可以看出，fbdev 主导了 Linux 显示的前二十年，而 DRM 则在过去十年中完成了全面替代。这一转变的背后，是显示硬件复杂度与用户空间需求的双重驱动。
1.2 fbdev 的辉煌与局限：为什么需要新框架？
fbdev（Frame Buffer Device）是 Linux 内核中最早的标准显示接口，其设计哲学是“将显存抽象为一个线性内存区域，用户空间直接读写即可刷新屏幕”。这一模型在 2D 时代非常高效，但随着 3D 加速、多显示器、合成桌面等需求的涌现，其固有缺陷逐渐暴露：
- 缺乏硬件加速抽象：fbdev 不提供 GPU 命令提交、上下文管理或显存分配接口，3D 渲染必须绕过内核直接操作硬件，导致安全性与可移植性差。
- 无原子模式设置：fbdev 的 mode-setting 是“先破坏再重建”的，切换分辨率或刷新率时会出现屏幕闪烁，无法实现平滑过渡。
- 多显示器支持薄弱：fbdev 的 /dev/fbX 设备是独立管理的，无法统一描述多个显示器的连接状态、EDID 信息或合成策略。
- 用户空间接口原始：ioctl 命令集有限，缺乏对缓冲区翻转（page-flip）、fence 同步、dma-buf 共享等现代特性的支持。
1.3 DRM 的崛起：现代显示栈的基石
DRM（Direct Rendering Manager）最初作为 DRI（Direct Rendering Infrastructure）项目的一部分进入内核，旨在为 3D 加速提供安全的用户空间访问路径。经过 KMS（Kernel Mode-Setting）与 atomic 接口的整合，DRM 已演变为一个完整的显示驱动框架，其核心能力包括：
- 统一的对象模型：CRTC、Encoder、Connector、Plane、Framebuffer 等内核对象，清晰描述显示流水线的每个环节。
- 原子模式设置：一次 ioctl 提交完整的显示状态变更，内核保证所有硬件寄存器同步更新，消除闪烁。
- 显存管理（GEM）：提供 buffer 分配、导入/导出、fence 同步机制，支持 dma-buf 跨设备共享。
- 合成与叠加：硬件 plane 支持多图层叠加，减少 GPU 合成负载，降低功耗。
- 用户空间友好：libdrm 封装内核接口，Wayland、X11、Android HWC 等上层组件均可直接使用。
下面的 SVG 图展示了现代 Linux DRM 显示栈的典型分层架构，帮助理解 DRM 在内核与用户空间之间的桥梁作用：
1.4 选型对比的现实意义：何时用 fbdev？何时用 DRM？
尽管 DRM 已成为主流，但 fbdev 并未完全消亡。在某些特定场景下，fbdev 仍然具有不可替代的优势。下表从多个维度对比两者的适用性：
| 对比维度 | fbdev | DRM / KMS |
|---|---|---|
| 硬件要求 | 仅需线性帧缓冲，无 GPU 也可运行 | 需要支持 KMS 的显示控制器，通常搭配 GPU |
| 驱动开发成本 | 低，几百行代码即可实现基本显示 | 高，需要实现 CRTC/Plane/GEM 等完整对象模型 |
| 功能特性 | 单缓冲、无硬件合成、无原子更新 | 多缓冲、硬件 plane 叠加、原子提交、fence 同步 |
| 用户空间生态 | 仅支持 fbdev 原生应用（如 fbi、DirectFB） | 支持 Wayland、X11、Android、游戏引擎等现代生态 |
| 多显示器支持 | 弱，需手动管理多个 /dev/fbX | 强，Connector 对象统一管理 EDID、热插拔、克隆/扩展 |
| 功耗优化 | 无硬件合成，GPU 需全帧合成，功耗高 | 硬件 plane 叠加，GPU 可休眠，功耗低 |
| 典型场景 | 低端嵌入式、UEFI 启动 splash、内核早期调试 | 智能手机、平板、桌面 GPU、汽车 IVI、机顶盒 |
1.5 演进路线图：从 fbdev 到 DRM 的迁移路径
对于正在从 fbdev 迁移到 DRM 的团队，理解两者的对应关系至关重要。下面的 SVG 图展示了 fbdev 核心概念在 DRM 中的映射关系，帮助开发者快速建立迁移认知：
从上图可以看出，fbdev 的每个核心概念在 DRM 中都有更精细、更强大的对应物。迁移不仅仅是 API 替换，更是显示架构思维的升级——从“像素搬运”到“显示流水线管理”。
1.6 本章小结
- fbdev 是历史产物：设计简单，但无法满足现代 GPU 合成、多显示器、原子更新等需求。
- DRM 是当前标准：提供完整的显示对象模型、显存管理、原子提交与硬件合成能力，是 Wayland/Android 等现代显示栈的基石。
- 选型需结合实际：新项目优先选择 DRM；遗留系统或极简场景可保留 fbdev，但需关注其维护状态。
- 迁移路径清晰：fbdev 的线性缓冲、显示参数、回调函数等概念均可映射到 DRM 的 framebuffer、connector、crtc_helper_funcs 等对象。