1. 课程导论：无GPU平台DRM驱动开发的挑战与drm_fbdev模拟层的价值

1.1 为什么需要无GPU平台的DRM驱动？

在嵌入式Linux系统中，大量低成本、低功耗的设备（如工业HMI、智能家居面板、车载仪表、IoT网关）并不配备独立的GPU硬件。然而，这些设备仍然需要高效的图形显示能力来呈现用户界面、视频流或状态信息。传统的帧缓冲（fbdev）驱动虽然简单，但存在多应用并发冲突、缺少VSync同步、无法与现代图形栈（如Wayland/Weston）集成等致命缺陷。

DRM（Direct Rendering Manager）子系统作为Linux内核中现代图形显示的标准框架，其设计初衷是面向具备GPU的桌面/移动平台。将DRM引入无GPU平台，意味着开发者需要解决以下核心矛盾：

• 硬件能力缺失：DRM原生的GEM（Graphics Execution Manager）和KMS（Kernel Mode Setting）假设存在GPU进行显存管理和渲染加速，无GPU平台只有简单的显示控制器和系统内存。
• API兼容性要求：用户空间图形栈（如libdrm、Mesa、Weston）期望通过DRM接口进行buffer分配、提交和页面翻转，无GPU驱动必须模拟这些行为。
• 性能与实时性：缺少硬件加速的2D/3D引擎，所有渲染必须依赖CPU，驱动层需要尽可能减少内存拷贝和上下文切换开销。

1.2 无GPU平台DRM开发的主要挑战

下表总结了在无GPU硬件上开发DRM驱动时面临的核心技术挑战及其影响：

1.3 drm_fbdev模拟层的设计价值

drm_fbdev模拟层（通常指内核中的drm_fbdev_generic或drm_fb_helper）是DRM子系统提供的一个关键基础设施，它允许无GPU的DRM驱动通过最小的代码量，同时支持：

• 传统fbdev兼容：为遗留的fbdev应用程序提供/dev/fb0设备节点，保持向后兼容。
• DRM原生接口：通过drm_fb_helper自动创建framebuffer对象，并注册到DRM主节点，使得libdrm和Wayland Compositor可以直接使用。
• 统一的buffer管理：模拟层负责在系统内存中分配连续物理内存（或通过DMA API分配），并映射为DRM framebuffer，驱动开发者无需手动处理buffer申请和释放。

下图展示了drm_fbdev模拟层在无GPU平台DRM驱动中的核心位置：

1.4 模拟层的核心工作机制

drm_fbdev模拟层的工作流程可以概括为以下四个步骤：

1. 初始化阶段：驱动在probe()中调用drm_fbdev_generic_setup()，模拟层自动分配一块连续物理内存作为默认framebuffer，并注册fbdev设备。
2. fbdev写入：用户空间通过write()或mmap()操作/dev/fb0，模拟层将数据拷贝到内核管理的shadow buffer中。
3. DRM提交：模拟层通过drm_fb_helper_damage_work()将脏区域（damage）提交到DRM framebuffer，触发drm_crtc_helper_set_config()进行模式设置。
4. 硬件刷新：驱动实现的crtc_helper_funcs->atomic_flush()将framebuffer内容通过DMA传输到显示控制器的输出缓冲区。

1.5 何时应该使用drm_fbdev模拟层？

并非所有无GPU平台都适合使用drm_fbdev模拟层。下表给出了决策参考：

1.6 课程路线图

本课程将围绕drm_fbdev模拟层，从零开始构建一个完整的无GPU平台DRM驱动。后续章节将依次覆盖：

• 第2-5章：DRM核心数据结构（drm_device、drm_driver、drm_mode_config）的初始化与注册。
• 第6-10章：KMS对象的实现——crtc、encoder、connector、plane的模拟层适配。
• 第11-15章：GEM对象与dumb buffer分配器，以及drm_fb_helper的集成。
• 第16-20章：atomic commit与vblank模拟，实现无撕裂的页面翻转。
• 第21-25章：fbdev兼容层的深度定制，包括ioctl处理、pan display、色彩模式转换。
• 第26-30章：实战案例——在QEMU模拟的ARM平台上运行完整DRM驱动，并验证Weston启动。