2、显示子系统基础：Linux显示栈概览（fbdev、DRM/KMS、Wayland/X11）、DRM架构组成（libdrm、内核模块、用户空间）及核心数据结构（drm_device、drm_driver）

Linux图形显示栈经历了从简单到复杂、从内核态到用户态协同演进的历程。早期基于framebuffer的fbdev架构仅提供最基础的显存映射与刷新能力，无法满足现代GPU的复杂管理需求（如多图层合成、垂直同步、显存管理、模式切换等）。DRM（Direct Rendering Manager）子系统应运而生，并逐渐成为Linux显示与渲染的事实标准。本章将系统梳理Linux显示栈的整体脉络，深入剖析DRM架构的内核/用户空间分工，并重点解读drm_device与drm_driver这两个核心数据结构的设计思想与工程含义。

上图展示了Linux显示栈的完整分层结构。从顶层应用到底层硬件，每一层都有明确的职责边界。理解这个栈的演进逻辑，是掌握DRM驱动开发的前提。下面我们逐层拆解。

2.1 Linux显示栈的演进：从fbdev到DRM/KMS

核心原理：fbdev的局限与DRM的诞生

fbdev（Framebuffer Device）是Linux早期为显示设备提供的统一抽象接口。它通过/dev/fbX设备节点，将显存映射到用户空间，应用程序可以直接读写帧缓冲。fbdev的设计极其简单：一个fb_info结构体描述显示参数（分辨率、色深、行距），一组fb_ops回调实现基本操作（set_var、set_par、blank等）。这种设计在嵌入式系统或简单LCD面板上非常有效，但面对现代GPU时暴露出严重问题：

• 无法管理多图层：现代显示控制器支持硬件图层叠加（如主层+光标层+视频层），fbdev只能暴露单一平面。
• 缺乏垂直同步机制：fbdev的刷新控制非常粗糙，容易产生画面撕裂（tearing）。
• 没有统一的显存管理：GPU显存与系统内存的映射、共享、同步缺乏标准接口。
• 模式切换不灵活：分辨率/刷新率的动态调整需要复杂的ioctl命令，且各驱动实现不一致。

DRM（Direct Rendering Manager）最初从XFree86/X.Org的DRI（Direct Rendering Infrastructure）项目中演化而来，2004年合入Linux 2.6.9内核。DRM的设计目标非常明确：为GPU提供安全的、可扩展的内核管理接口，同时将渲染相关的硬件操作尽可能下沉到用户空间。DRM核心提供设备管理、内存管理（GEM/TTM）、同步对象（fence）等基础框架，而具体的GPU硬件差异由各个厂商驱动（i915、amdgpu、msm等）实现。

判断方法：何时选择fbdev，何时必须用DRM

在实际工程中，选择哪种显示框架取决于硬件能力和产品需求：

值得注意的是，现代内核中DRM驱动通常会提供fbdev兼容层（drm_fb_helper），通过模拟/dev/fb0让传统应用继续工作。但这只是兼容手段，新开发的功能应直接使用DRM接口。

案例拆解：一个嵌入式产品的显示方案选型

假设我们设计一款工业HMI（人机界面）设备，采用全志T113处理器（集成Mali-400 GPU），运行Linux 5.15内核，需要支持1080p HDMI输出和7寸LVDS触摸屏。产品需求包括：

• Qt5应用，需要OpenGL ES 2.0硬件加速渲染
• 支持双屏异显（HDMI显示视频，LVDS显示控制面板）
• 要求无撕裂，视频播放流畅

如果选择fbdev方案，Qt的OpenGL渲染将无法使用GPU加速（fbdev不支持DRI），只能使用软件渲染（llvmpipe），1080p下性能严重不足。同时双屏管理在fbdev中需要两个/dev/fb节点，且无法实现硬件图层叠加。最终方案必须采用DRM/KMS：

1. 内核配置CONFIG_DRM、CONFIG_DRM_LIMA（Mali-400开源驱动）
2. 用户空间使用libdrm + Mesa3D（提供OpenGL ES实现）
3. Qt平台插件选择eglfs，直接基于DRM/KMS输出
4. 双屏通过两个DRM connector分别配置

这个案例说明，当产品涉及GPU加速或复杂显示需求时，fbdev是技术死胡同，必须从一开始就规划DRM路线。

常见误区与总结

总结：fbdev是历史遗留的简单抽象，DRM/KMS是面向现代GPU的完整解决方案。理解两者的设计哲学差异，是选择正确技术路线的基础。

2.2 DRM架构组成：内核模块、libdrm与用户空间协同

核心原理：三层架构的职责划分

DRM架构严格遵循"内核最小化、用户空间最大化"的原则。整个DRM系统分为三个层次：

内核层（DRM Core + 厂商驱动）：负责硬件资源管理、安全访问控制、模式设置（KMS）、内存管理（GEM）、同步原语（fence）。内核层通过struct drm_driver定义驱动接口，通过struct drm_device表示一个显示设备实例。厂商驱动（如i915.ko、amdgpu.ko）实现具体的硬件操作回调。

用户空间库层（libdrm）：libdrm是内核DRM接口的C语言封装，提供drmOpen()、drmModeGetResources()、drmModeSetCrtc()等API。它隐藏了ioctl的细节，为上层提供类型安全的接口。libdrm还包含drm_memory、drm_fence等辅助模块。

应用层（Mesa/合成器/应用）：Mesa3D通过libdrm与内核交互，实现OpenGL/Vulkan的硬件加速；Wayland合成器（如Weston）使用libdrm的KMS接口控制显示输出；X11的DDX驱动也基于libdrm。

操作流程：从打开设备到显示一帧画面

一个典型的DRM显示流程如下：

// 1. 打开DRM设备
int fd = open("/dev/dri/card0", O_RDWR);
drmModeRes *res = drmModeGetResources(fd);

// 2. 查找connector和encoder
drmModeConnector *conn = drmModeGetConnector(fd, res->connectors[0]);
drmModeEncoder *enc = drmModeGetEncoder(fd, res->encoders[0]);

// 3. 创建framebuffer（分配显存并绑定）
uint32_t fb_id;
drmModeAddFB(fd, width, height, depth, bpp, pitch, handle, &fb_id);

// 4. 设置CRTC（连接encoder和framebuffer）
drmModeSetCrtc(fd, enc->crtc_id, fb_id, x, y, &conn->connector_id, 1, &mode);

// 5. 渲染后提交（Page Flip）
drmModePageFlip(fd, crtc_id, fb_id, DRM_MODE_PAGE_FLIP_EVENT, NULL);

这个流程展示了DRM的核心操作模式：所有配置通过ioctl完成，所有对象通过ID引用。内核不直接暴露结构体指针，而是通过整数ID进行安全引用。

案例拆解：调试一个"黑屏无输出"问题

假设我们在RK3588平台上开发DRM驱动，遇到HDMI输出黑屏。按照以下步骤排查：

1. 检查设备节点：ls /dev/dri/，确认card0存在。如果不存在，检查内核日志dmesg | grep drm。
2. 检查连接状态：使用modetest -M rockchip（libdrm测试工具）查看connector状态。输出connected表示物理链路正常，disconnected则检查HDMI线缆和硬件。
3. 检查模式设置：modetest -M rockchip -s 42:1920x1080强制设置分辨率。如果报错Invalid argument，可能是timing参数不匹配。
4. 检查framebuffer：确认drmModeAddFB的pitch计算正确，特别是当宽度不是64字节对齐时。
5. 检查Page Flip：如果静态画面正常但动态画面黑屏，可能是fence等待超时，检查GPU渲染是否完成。

这个案例说明，DRM调试需要分层排查：设备层→连接层→模式层→缓冲层→渲染层。

常见误区与总结

总结：DRM的三层架构实现了"内核管资源、用户管策略"的优雅分工。理解每个层次的边界，是编写高效显示应用的基础。

2.3 核心数据结构：drm_device与drm_driver

核心原理：两个结构体的角色定位

struct drm_device是DRM子系统中最重要的核心对象，它代表一个完整的显示/渲染设备实例。在系统中有几个GPU，就有几个drm_device实例。其主要成员包括：

• struct drm_driver *driver：指向该设备对应的驱动操作集
• struct drm_minor *primary：主设备节点（cardX）
• struct drm_minor *render：渲染设备节点（renderD128）
• struct drm_mode_config mode_config：KMS配置管理（包含所有CRTC、Encoder、Connector、Plane）
• struct drm_file *filelist：打开该设备的文件句柄列表
• struct mutex struct_mutex：保护设备状态的主锁
• struct idr object_name_idr：对象ID分配器（用于GEM对象等）

struct drm_driver则定义了驱动的能力与回调函数。它是内核与厂商驱动之间的"契约"。关键成员包括：

• int (*load)(struct drm_device *, unsigned long flags)：驱动加载入口（已废弃，推荐用drm_dev_register）
• int (*open)(struct drm_device *, struct drm_file *)：设备打开时的回调
• void (*lastclose)(struct drm_device *)：最后一个文件关闭时触发（用于恢复显示状态）
• const struct file_operations *fops：设备文件操作集
• const struct drm_ioctl_desc *ioctls：驱动自定义ioctl表
• const struct drm_gem_object_funcs *gem_funcs：GEM对象操作
• int (*dumb_create)(struct drm_file *, struct drm_device *, struct drm_mode_create_dumb *)：创建 dumb buffer（用于KMS显示）

判断方法：如何理解驱动与设备的关系

在Linux设备模型中，drm_driver类似于struct device_driver，而drm_device类似于struct device。但DRM做了抽象：一个drm_driver可以管理多个drm_device（例如双GPU系统）。驱动注册流程如下：

// 厂商驱动定义
static const struct drm_driver foo_driver = {
    .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_RENDER,
    .fops = &foo_fops,
    .gem_funcs = &foo_gem_funcs,
    .dumb_create = foo_dumb_create,
    .ioctls = foo_ioctls,
    .num_ioctls = ARRAY_SIZE(foo_ioctls),
    .name = "foo",
    .desc = "Foo GPU Driver",
    .major = 1, .minor = 0,
};

// 平台驱动probe函数中
struct drm_device *dev = drm_dev_alloc(&foo_driver, &pdev->dev);
// 初始化硬件、设置mode_config等
drm_dev_register(dev, 0);

这里的关键点是：drm_dev_alloc分配并初始化drm_device，drm_dev_register创建设备节点并暴露给用户空间。

案例拆解：一个简单DRM驱动的骨架

假设我们要为一个虚拟GPU编写DRM驱动（类似virtio-gpu），核心实现如下：

// 1. 定义GEM对象操作
static const struct drm_gem_object_funcs foo_gem_funcs = {
    .free = foo_gem_free,
    .print_info = foo_gem_print_info,
    .export = drm_gem_prime_export,
    .import = drm_gem_prime_import,
};

// 2. 实现dumb_create（用于KMS显示缓冲）
static int foo_dumb_create(struct drm_file *file_priv,
                           struct drm_device *dev,
                           struct drm_mode_create_dumb *args)
{
    // 计算pitch（64字节对齐）
    args->pitch = ALIGN(args->width * args->bpp / 8, 64);
    args->size = args->pitch * args->height;
    // 分配物理内存并创建GEM对象
    return foo_gem_create(file_priv, dev, args->size, &args->handle);
}

// 3. 定义ioctl表
static const struct drm_ioctl_desc foo_ioctls[] = {
    DRM_IOCTL_DEF_DRV(FOO_SUBMIT, foo_submit_ioctl, DRM_RENDER_ALLOW),
};

// 4. 定义file operations
static const struct file_operations foo_fops = {
    .owner = THIS_MODULE,
    .open = drm_open,
    .release = drm_release,
    .unlocked_ioctl = drm_ioctl,
    .mmap = drm_gem_mmap,
    .poll = drm_poll,
};

// 5. 注册平台驱动
static int foo_pdev_probe(struct platform_device *pdev)
{
    struct drm_device *ddev;
    ddev = drm_dev_alloc(&foo_driver, &pdev->dev);
    // 初始化mode_config（设置CRTC/Encoder/Connector）
    foo_mode_config_init(ddev);
    drm_dev_register(ddev, 0);
    platform_set_drvdata(pdev, ddev);
    return 0;
}

这个骨架展示了DRM驱动的标准实现模式：分配设备→初始化配置→注册设备。实际驱动还需要实现KMS回调（如crtc_helper_funcs）、GEM内存管理、fence同步等。

常见误区与总结

总结：drm_device是"设备实例"，drm_driver是"驱动能力描述"。两者通过drm_dev_alloc绑定，构成了DRM驱动的核心骨架。深入理解这两个结构体的生命周期和成员含义，是编写正确DRM驱动的第一步。