Linux帧缓冲与DRM显示驱动开发实战 - 第1节
1.1 Linux 显示子系统整体架构
Linux 显示子系统是操作系统图形栈的核心，负责将应用程序的渲染结果最终呈现在物理显示设备上。其架构采用分层设计，从上到下依次为：用户空间图形库、内核空间显示驱动框架以及硬件层。理解这一分层结构是开发显示驱动的第一步。
核心分层原则： 用户空间关注“如何绘制”，内核空间关注“如何控制硬件并管理显存”，硬件层负责“物理信号输出”。
1.1.1 架构分层与职责
| 层级 | 典型组件 | 核心职责 |
|---|---|---|
| 用户空间应用 | GUI 框架 (Qt, GTK), 游戏引擎, Wayland/Weston | 发起绘制请求，管理窗口合成 |
| 用户空间库 | libdrm, Mesa 3D, EGL, libinput | 封装内核接口，提供硬件加速抽象 |
| 内核空间 (核心) | DRM/KMS 子系统, FBDEV (帧缓冲设备) | 显存管理、模式设置、命令提交、同步 |
| 硬件层 | GPU, Display Controller, HDMI/DP 物理层 | 像素渲染、扫描输出、信号编码 |
1.2 帧缓冲 (FB) 与 DRM/KMS 的关系
在 Linux 内核中，存在两套并行的显示驱动框架：传统的 帧缓冲 (FrameBuffer, FBDEV) 和现代的 DRM/KMS (Direct Rendering Manager / Kernel Mode Setting)。理解两者的演进与差异，是选择正确开发路径的关键。
1.2.1 帧缓冲 (FBDEV) 框架
FBDEV 是 Linux 内核中最早出现的显示框架，通过 /dev/fbX 设备文件向用户空间提供简单的显存访问接口。其核心思想是：用户空间通过 mmap 映射显存，直接操作像素数据，内核负责将显存内容扫描输出到显示器。
- 优点： 接口简单，易于实现，适合无 GPU 的嵌入式系统或早期启动阶段 (splash screen)。
- 缺点： 不支持硬件图层叠加、不支持垂直同步 (VBlank) 同步、多显示器支持困难、无法利用 GPU 加速。
- 关键数据结构：
struct fb_info和struct fb_var_screeninfo。
注意： 在主流桌面 Linux 发行版中，FBDEV 已被标记为“遗留”驱动。但对于资源受限的嵌入式设备（如单片机+LCD 屏），FBDEV 仍然是轻量级的选择。
1.2.2 DRM/KMS 框架
DRM (Direct Rendering Manager) 最初是为 GPU 的 3D 加速而设计，后来演变为统一的显示驱动框架。KMS (Kernel Mode Setting) 是 DRM 的一部分，负责显示模式（分辨率、刷新率、图层）的设置。DRM/KMS 是现代 Linux 显示的标准。
- 核心对象： CRTC (显示控制器)、Encoder (编码器)、Connector (连接器)、Plane (图层)、Framebuffer (帧缓冲对象)。
- 关键特性： 支持原子提交 (Atomic Commit)、VBlank 同步、硬件图层合成、多显示器独立配置。
- 用户空间接口：
/dev/dri/card0，通过libdrm库进行 ioctl 调用。
1.2.3 核心差异对比
| 对比维度 | FBDEV (帧缓冲) | DRM/KMS |
|---|---|---|
| 设备节点 | /dev/fb0 |
/dev/dri/card0 |
| 核心能力 | 仅显存读写与扫描输出 | 显存管理 + 模式设置 + 命令提交 + 同步 |
| 硬件图层 | 不支持 | 支持 (Plane 对象) |
| 多显示器 | 需多个 /dev/fbX 实例 |
原生支持，通过 Connector 管理 |
| GPU 加速 | 不支持 | 原生支持 (GEM 显存管理) |
| 垂直同步 | 需手动实现 | 内置 VBlank 事件机制 |
| 当前状态 | 遗留 (Legacy) | 标准 (Standard) |
1.3 用户空间与内核空间交互机制
显示驱动的核心价值在于为用户空间提供高效、安全的硬件控制能力。Linux 通过系统调用、设备文件、内存映射和事件机制，实现了用户空间与内核空间显示驱动的交互。
1.3.1 交互通道与接口
- 设备文件： 用户空间通过
open()打开/dev/fb0或/dev/dri/card0获取文件描述符。 - 系统调用 (ioctl)： 核心控制命令通过
ioctl()传递。例如，FBDEV 的FBIOGET_VSCREENINFO，DRM 的DRM_IOCTL_MODE_GETRESOURCES。 - 内存映射 (mmap)： 将内核显存映射到用户空间地址，实现零拷贝像素数据访问。
- 事件机制： 通过
poll()或select()监听 VBlank 事件、热插拔事件等。
1.3.2 交互流程示例 (DRM 模式设置)
以下是一个典型的 DRM 应用初始化流程，展示了用户空间如何通过 libdrm 与内核交互：
// 1. 打开 DRM 设备
int fd = open("/dev/dri/card0", O_RDWR);
// 2. 获取资源 (CRTC, Encoder, Connector)
drmModeRes *resources = drmModeGetResources(fd);
// 3. 获取 Connector 当前模式
drmModeConnector *connector = drmModeGetConnector(fd, resources->connectors[0]);
drmModeModeInfo *mode = &connector->modes[0];
// 4. 创建 Framebuffer (分配显存)
uint32_t fb_id;
drmModeAddFB(fd, mode->hdisplay, mode->vdisplay, 24, 32,
mode->hdisplay * 4, &fb_id);
// 5. 设置 CRTC (连接 Framebuffer 到 Connector)
drmModeSetCrtc(fd, resources->crtcs[0], fb_id, 0, 0,
&resources->connectors[0], 1, mode);
// 6. 映射显存并绘制
uint32_t *map = mmap(0, mode->hdisplay * mode->vdisplay * 4,
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 绘制像素...
关键点： 用户空间通过
libdrm 库封装了底层的 ioctl 调用。驱动开发者需要在内核侧实现对应的 ioctl 处理函数，例如 drm_mode_addfb 和 drm_mode_setcrtc。
1.3.3 数据流与事件流
1.4 本章小结
- Linux 显示子系统采用 用户空间库 → 内核驱动 → 硬件 的三层架构。
- FBDEV 是遗留框架，接口简单但功能有限；DRM/KMS 是现代标准，支持原子操作、图层和 GPU 加速。
- 用户空间通过 设备文件、ioctl、mmap、事件机制 与内核驱动交互，其中
libdrm是 DRM 框架的标准用户空间库。 - 驱动开发者的核心工作是在内核侧实现 struct drm_driver 或 struct fb_ops 中的回调函数，以响应来自用户空间的请求。