从FB到DRM/KMS：一个嵌入式老鸟的显示驱动踩坑与升级实录

在RK3568智能终端项目的第37天深夜，当第8次尝试让四层UI合成显示时，我的开发板突然蓝屏了——这成了压垮FrameBuffer架构的最后一根稻草。作为从业12年的嵌入式工程师，我清楚意识到：是时候拥抱DRM/KMS了。这不是简单的API替换，而是一次从马车到高铁的架构跃迁。

1. 技术选型：为什么必须放弃FrameBuffer

2010年我刚入行时，FrameBuffer还是嵌入式显示的标配。就像老式的显像管电视，它用最简单的映射机制将内存区域直接输出到屏幕。但当我们项目需要实现这些功能时，FB的局限性彻底暴露：

• 多层合成：UI控件、视频流、动态菜单需要独立图层
• 硬件光标：60fps无闪烁的指针运动
• VSYNC同步：避免画面撕裂的垂直同步信号
• 内存共享：GPU和显示驱动间的DMA-BUF传递

对比测试数据最能说明问题：

提示：当你的项目需要实现动态UI效果时，FB架构的软件合成会吃掉30%以上的CPU资源

2. DRM驱动移植实战：从零搭建显示流水线

2.1 硬件抽象层改造

RK3568的显示子系统包含三个关键IP核：VOP（视频输出处理器）、HDMI TX、MIPI DSI。在DRM框架下，我们需要重新定义这些硬件组件：

c复制static const struct drm_encoder_funcs rockchip_encoder_funcs = {
    .destroy = drm_encoder_cleanup,
};

static struct drm_connector *rockchip_mipi_connector_init(
    struct drm_device *drm, struct device_node *np) {
    /* 实现EDID读取和热插拔检测 */
}

关键步骤拆解：

1. 初始化GEM内存管理器：配置CMA和ION两种内存分配策略
2. 注册CRTC对象：绑定VOP的中断服务例程
3. 构建显示管线：Connector→Encoder→CRTC的拓扑验证
4. 实现原子提交：通过drm_atomic_helper_commit()处理模式切换

2.2 多图层合成陷阱

在实现Plane子系统时，我踩过一个典型坑：当同时启用Primary Plane和Overlay Plane时，屏幕出现雪花噪点。通过逻辑分析仪抓取信号发现：

code复制[ 273.456721] vop ff8f0000.vop: [drm:vop_crtc_atomic_flush] 
* ERROR* win0 enable but no valid buffer

根本原因是DMA地址未对齐到64字节边界。解决方案是在分配缓冲区时添加约束：

c复制struct drm_mode_create_dumb create_arg = {
    .width = ALIGN(width, 64),
    .height = height,
    .bpp = 32,
};

3. 性能调优：从能用变好用

3.1 垂直同步的艺术

没有VSYNC的显示系统就像没有刹车的跑车。我们通过DRM的事件机制实现帧精确控制：

python复制def wait_vsync():
    fd = open("/dev/dri/card0", "rb")
    drm.event_read(fd)  # 阻塞等待垂直空白
    flip_time = time.monotonic()
    return flip_time

实测数据显示，启用VSYNC后：

• 画面撕裂率从15%降至0%
• 动态菜单滑动流畅度提升40%
• GPU负载降低22%（避免过度渲染）

3.2 内存管理黑科技

传统FB的单一缓冲导致频繁的显存拷贝。DRM的GEM子系统支持三种高级特性：

1. Prime Buffer共享：实现零拷贝视频流传输
2. Fence同步：GPU和显示驱动的执行依赖管理
3. FB-DAMAGE：智能脏矩形更新

bash复制# 查看DRM内存状态
cat /sys/kernel/debug/dri/0/mm

4. 升级收益：数字不会说谎

项目上线三个月后，量化指标验证了架构升级的价值：

最让我意外的是维护成本的变化——过去需要2周才能添加的新显示特性，现在平均3天就能完成。这让我有更多时间思考产品创新，而不是在寄存器配置里挣扎。