1. fbdev 概述：fbdev 在 Linux 图形栈中的位置、与 DRM/KMS 的对比、适用场景分析
1.1 fbdev 在 Linux 图形栈中的位置
fbdev（Frame Buffer Device）是 Linux 内核中历史最悠久的图形显示子系统，自 2.2 内核时代起便作为标准框架存在。它通过 /dev/fb* 设备节点向用户空间暴露一个线性帧缓冲（framebuffer），应用程序可以直接通过 mmap() 系统调用映射该缓冲区，并向其中写入像素数据，无需经过复杂的图形管线。
在 Linux 图形栈中，fbdev 位于最底层，直接与硬件显示控制器交互，向上为 X.Org、Wayland、Qt/Embedded 等图形系统提供最基础的显示能力。其典型层次结构如下：
层次位置说明： 用户空间应用 → 图形库（如 Cairo、Qt） → 显示服务器（X.Org / Wayland） → 内核 fbdev 驱动 → 硬件显示控制器 → 显示面板。
1.2 fbdev 与 DRM/KMS 的对比
DRM（Direct Rendering Manager）与 KMS（Kernel Mode Setting）是 Linux 内核中新一代的图形显示框架，自 2.6.29 内核引入后逐渐成熟，并在现代 Linux 发行版中取代了 fbdev 的主导地位。两者在架构设计、功能特性和性能表现上存在显著差异：
| 对比维度 | fbdev | DRM/KMS |
|---|---|---|
| 内核版本 | Linux 2.2+（1999 年） | Linux 2.6.29+（2009 年） |
| 设备节点 | /dev/fb[0-9] |
/dev/dri/card[0-9] |
| 模式设置 | 通过 FBIOGET_VSCREENINFO / FBIOPUT_VSCREENINFO ioctl |
通过 KMS atomic API / drm_mode_setcrtc |
| 多缓冲支持 | 有限，通常仅支持单缓冲或双缓冲（需驱动实现） | 原生支持双缓冲、三缓冲、平面（plane）合成 |
| 硬件加速 | 无，纯软件渲染 | 支持 GPU 加速渲染、GEM/TTM 内存管理 |
| 多显示器 | 通过多个 /dev/fb* 设备模拟，缺乏统一管理 |
原生支持多 CRTC、多连接器（connector）管理 |
| 原子更新 | 不支持，配置切换可能产生撕裂 | 支持 atomic modeset，无撕裂切换 |
| 驱动复杂度 | 较低，约 500-2000 行代码 | 较高，约 5000-50000 行代码 |
关键差异总结： fbdev 是一个“简单粗暴”的帧缓冲暴露框架，适合快速实现基本显示功能；DRM/KMS 则是一个完整的显示管理框架，提供了原子模式设置、GPU 加速、多平面合成等现代图形系统所需的核心能力。
1.3 fbdev 的适用场景分析
尽管 DRM/KMS 已成为主流，fbdev 在特定场景下仍然具有不可替代的价值。以下从实际工程角度分析 fbdev 的适用场景：
1.3.1 嵌入式系统与低端硬件
- 资源受限设备： 内存小于 64MB、无 GPU 或仅有简单显示控制器的 MCU/MPU 平台（如 STM32MP1、NXP i.MX6ULL）。
- 快速原型开发： 需要最短时间点亮屏幕、验证硬件时，fbdev 驱动开发周期通常只需 1-3 天。
- 实时系统： 在 RT-Linux 或裸机环境下，fbdev 的确定性内存访问模式更易满足实时性要求。
1.3.2 控制台与调试场景
- fbcon： Linux 内核的帧缓冲控制台（fbcon）依赖 fbdev 实现文本模式显示，在系统启动早期、X11/Wayland 未启动时提供调试输出。
- 紧急恢复： 当 DRM/KMS 驱动崩溃或 GPU 挂起时，fbdev 可作为 fallback 显示方案。
- 内核调试： 通过
earlyfb或simplefb在引导阶段提供早期显示支持。
1.3.3 特殊显示需求
- 单色/低色深显示： 如电子墨水屏、单色 OLED、段式 LCD，fbdev 的简单接口更易适配。
- 非标准分辨率： 某些工业显示屏使用非标准时序，fbdev 的灵活配置接口更易调整。
- 虚拟显示： 如 QEMU 的
virtio-gpu在 legacy 模式下仍使用 fbdev 接口。
注意： 对于需要 GPU 加速、多窗口合成、高刷新率（>60fps）或 4K 以上分辨率的场景，fbdev 已完全无法满足需求，必须使用 DRM/KMS。fbdev 在 2020 年后的内核中已被标记为“遗留（legacy）”子系统，新驱动开发应优先选择 DRM/KMS。