1. 课程导入

在嵌入式 Linux、国产 SoC、车载座舱、工业 HMI 与消费类终端中，显示子系统往往是最容易“点亮”也最容易“踩坑”的模块之一。早期方案常用 Framebuffer（fbdev）快速把 Logo 和 UI 显示出来，但当项目需要多图层合成、硬件光标、页面翻转、垂直同步、HDMI 热插拔、多屏异显、GPU 与显示控制器协同、安全显示通道时，fbdev 的抽象能力就明显不足。DRM/KMS 因此成为现代显示驱动的主流框架。本课程围绕“从 Framebuffer 到 DRM 的显示驱动移植适配”展开，目标不是背诵 API，而是建立一套可复用的工程方法：看懂旧驱动、拆解显示链路、映射到 DRM 对象、完成 bring-up、定位黑屏/花屏/撕裂/闪烁等问题，并最终形成可维护的移植方案。

学习目标

• 理解 fbdev 与 DRM/KMS 在抽象模型、内存管理、显示管线、事件机制上的核心差异。
• 掌握显示驱动移植的通用流程：硬件资料梳理、时钟与电源确认、时序参数提取、驱动骨架搭建、调试与验证。
• 能够把旧 Framebuffer 驱动中的 panel、controller、DMA、中断、GPIO、背光等要素映射到 DRM 的 CRTC、Encoder、Connector、Plane、Bridge、Panel 等对象。
• 具备独立排查黑屏、花屏、颜色异常、撕裂、闪屏、热插拔失败等常见问题的能力。
• 形成“先链路、后参数、再调试”的工程思维，而不是盲目改代码。

显示驱动演进背景

Framebuffer 时代，显示驱动通常只做一件事：申请一块连续或非连续显存，配置显示控制器扫描输出，向上提供一个 /dev/fbX 设备。应用通过 ioctl 设置分辨率、像素格式和刷新，内核通过 fb_ops 完成初始化、设置参数、空白等操作。它的优点是简单、直接、启动快，适合单图层、固定分辨率、无复杂合成的场景。

但随着 SoC 显示控制器越来越复杂，fbdev 的局限逐渐暴露：没有标准的图层抽象，多图层合成往往依赖厂商私有 ioctl；没有统一的页面翻转和垂直同步事件， tearing 难以避免；没有标准的连接器与热插拔模型，HDMI/DP 的 EDID 解析和模式切换难以复用；没有统一的原子提交机制，多屏、多图层、多 plane 的配置容易产生中间状态。DRM/KMS 正是在这种背景下成为 Linux 显示子系统的事实标准。

Framebuffer 与 DRM 的核心差异

理解差异是移植的前提。下面从抽象模型、内存、显示管线、事件与调试五个维度进行对比。

从工程角度看，fbdev 驱动中的“设置分辨率”往往对应 DRM 中的“模式设置 + 原子提交”；fbdev 中的“切换显存地址”对应 DRM 中的“Plane 更新 + Page Flip”；fbdev 中的“背光开关”对应 DRM Panel 或 Backlight 子系统的标准接口。只有完成这种语义映射，移植才不会变成“照抄代码”。

整体课程框架与实战路线

本课程共 30 章，按照“认知 → 拆解 → 移植 → 调试 → 优化 → 复盘”的路线推进。前几章建立 Framebuffer 与 DRM 的全局认知，随后进入显示链路拆解、设备树与时钟电源、Panel 与背光、CRTC/Plane/Encoder/Connector 的驱动实现，再进入原子提交、Page Flip、DMA-BUF、多屏与热插拔等进阶主题，最后通过真实案例复盘黑屏、花屏、撕裂、闪屏等问题的定位方法。

1. 认知阶段：理解 fbdev 与 DRM 的差异，建立显示流水线模型。
2. 拆解阶段：从原理图、时序手册、旧驱动中提取关键参数与硬件行为。
3. 移植阶段：搭建 DRM 驱动骨架，完成 CRTC、Plane、Encoder、Connector、Panel 的适配。
4. 调试阶段：使用 modetest、kmscube、drm_info、debugfs 验证链路与状态。
5. 优化阶段：处理撕裂、闪烁、带宽、功耗、多屏同步与热插拔。
6. 复盘阶段：沉淀检查清单、日志模板与可复用的移植经验。

案例场景：一次典型的 fbdev 到 DRM 移植

假设某工业 HMI 项目原方案使用 800×480 RGB 屏，旧驱动基于 fbdev，启动时直接配置 LCD 控制器寄存器并申请一块固定显存。现在要升级到支持双图层、页面翻转和 HDMI 扩展显示的 DRM 方案。移植时，首先要把旧驱动中的时序参数提取出来：

/* 旧 fbdev 驱动中的典型时序参数 */
.hdisplay       = 800,
.hsync_start    = 800 + 40,
.hsync_end      = 800 + 40 + 48,
.htotal         = 800 + 40 + 48 + 40,
.vdisplay       = 480,
.vsync_start    = 480 + 13,
.vsync_end       = 480 + 13 + 3,
.vtotal         = 480 + 13 + 3 + 29,
.pixelclock     = 33000000,

这些参数在 DRM 中会转化为 drm_display_mode，并通过 Panel 或 Bridge 的 get_modes 返回。旧驱动中直接写寄存器的部分，则要拆分为 CRTC 的 mode_set、Plane 的 atomic_update、Encoder 的 enable/disable 以及 Connector 的 detect/get_modes。原来通过私有 ioctl 完成的“切换显存地址”，要改为 DRM Page Flip；原来通过轮询等待 vsync 的逻辑，要改为 vblank 事件或 atomic commit 完成回调。

常见误区与复盘

• 误区一：把 DRM 当成“另一个 Framebuffer”。DRM 的核心是对象模型和原子状态机，如果只改 API 名称而不理解提交语义，后续多图层和热插拔一定会出问题。
• 误区二：忽略设备树与时钟电源。很多黑屏不是驱动逻辑错误，而是 pixel clock、PLL、电源域、复位 GPIO 或背光使能没有正确配置。
• 误区三：时序参数照抄旧驱动但不验证。不同 Panel 对前后肩、同步极性、DE 极性要求不同，必须结合手册和示波器/逻辑分析仪确认。
• 误区四：调试只靠 printk。DRM 提供了丰富的 debugfs 和 atomic state 日志，善用 drm_info、modetest 和内核日志能大幅缩短定位时间。
• 误区五：忽视内存与带宽。高分辨率、多图层、高刷新率场景下，DMA-BUF 格式、stride、对齐和带宽预算会直接影响是否花屏或掉帧。