当前位置：首页 > news >正文

从/dev/fb0到DRM：一个嵌入式Linux工程师的显示框架演进笔记

news 2026/6/14 9:25:09

从/dev/fb0到DRM：一个嵌入式Linux工程师的显示框架演进笔记

第一次在嵌入式设备上点亮LCD屏幕时，那种成就感至今难忘。那是一个简单的800x480电阻屏，通过FrameBuffer驱动直接映射内存操作像素，几行代码就能让屏幕显示彩色条纹。但随着项目需求从"能显示就行"升级到"流畅的UI动画"，我开始意识到传统FB框架的局限性。这篇文章记录了我从FB到DRM的技术转型历程，包含实际项目中的代码片段、调试经验和架构思考。

1. FrameBuffer：简单直接的显示方案

早期的嵌入式显示需求往往只需要静态画面或简单动画，FB框架完美契合这种场景。记得第一次成功驱动LCD时，设备树中只需定义如下节点：

framebuffer@0 { compatible = "simple-framebuffer"; memory-region = <&display_reserved>; width = <800>; height = <480>; stride = <1600>; // bytes per line format = "r5g6b5"; };

应用程序通过mmap直接操作显存的方式简单粗暴：

int fd = open("/dev/fb0", O_RDWR); struct fb_var_screeninfo vinfo; ioctl(fd, FBIOGET_VSCREENINFO, &vinfo); char *buffer = mmap(NULL, vinfo.yres_virtual * vinfo.xres_virtual * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); // 绘制红色矩形 for (int y = 100; y < 200; y++) { for (int x = 100; x < 200; x++) { int location = (x + vinfo.xoffset) * 2 + (y + vinfo.yoffset) * vinfo.xres_virtual * 2; *((unsigned short*)(buffer + location)) = 0xF800; // RGB565红色 } }

FB框架的核心优势在于：

开发门槛低：无需理解复杂显示流水线
资源占用小：内核模块仅需几十KB
实时性强：直接内存操作无中间层开销

但随着项目演进，FB的缺陷逐渐显现：

无硬件加速：CPU软渲染占用大量资源
单缓冲问题：画面撕裂现象严重
缺乏合成能力：无法实现图层叠加
刷新控制弱：难以精确同步垂直同步信号

实际项目中遇到的典型问题：当UI需要实现60fps动画时，CPU使用率常超过70%，导致系统响应迟缓。

2. 项目痛点驱动的技术转型

转折点出现在需要实现智能家居中控界面时，产品要求：

多图层合成（背景、视频、UI控件）
60fps流畅动画
动态分辨率切换
低功耗待机画面保持

FB框架已无法满足这些需求，技术评估后我们决定转向DRM框架。迁移过程中遇到的首个挑战是概念转换：

FB概念	DRM对应	差异说明
/dev/fbX	/dev/dri/cardX	从单一设备到统一管理接口
mmap操作	GEM对象管理	显存变为抽象资源
直接绘制	原子提交	事务性显示更新
pan_display	page_flip	完整的帧缓冲切换机制

设备树配置也变得更加复杂：

ltdc: display-controller@5a001000 { compatible = "st,stm32-ltdc"; reg = <0x5a001000 0x400>; interrupts = <88>, <89>; clocks = <&rcc LTDC_PX>; clock-names = "lcd"; resets = <&rcc LTDC_R>; status = "okay"; port { #address-cells = <1>; #size-cells = <0>; ltdc_out_rgb: endpoint { remote-endpoint = <&panel_input>; }; }; }; panel: panel { compatible = "panel-dpi"; label = "lcd-panel"; port { panel_input: endpoint { remote-endpoint = <&ltdc_out_rgb>; }; }; // 详细时序参数... };

3. DRM框架深度实践

DRM的核心优势在于其模块化设计。通过KMS(Kernel Mode Setting)子系统，我们可以精细控制显示流水线的每个环节：

graph LR APP[应用程序] -->|libdrm| KMS subgraph DRM驱动 KMS --> CRTC CRTC --> Plane Plane --> FB[Framebuffer] CRTC --> Encoder Encoder --> Connector end Connector --> Display[物理显示器]

实际项目中最常用的API调用流程：

资源获取：

drmModeRes *res = drmModeGetResources(fd); drmModeConnector *conn = drmModeGetConnector(fd, res->connectors[0]); drmModeEncoder *enc = drmModeGetEncoder(fd, conn->encoder_id); drmModeCrtc *crtc = drmModeGetCrtc(fd, enc->crtc_id);

双缓冲设置：

struct drm_mode_create_dumb creq = {0}; creq.width = width; creq.height = height; creq.bpp = 32; drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq); drmModeAddFB(fd, width, height, 24, 32, creq.pitch, creq.handle, &fb_id);

原子提交：

drmModeAtomicReq *req = drmModeAtomicAlloc(); drmModeAtomicAddProperty(req, plane_id, prop_ids[PLANE_FB_ID], fb_id); drmModeAtomicAddProperty(req, plane_id, prop_ids[PLANE_CRTC_ID], crtc_id); drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);

调试经验：使用DRM_IOCTL_MODE_GETPROPERTY可以枚举所有可用属性，这在适配新硬件时特别有用。

4. 性能优化实战技巧

经过多个项目迭代，总结出以下DRM优化方案：

内存管理优化：

// 使用CMA连续内存 struct drm_mode_create_dumb creq = { .flags = DRM_MODE_CREATE_DUMB_CMA, .width = width, .height = height, .bpp = 32, }; // 启用FB_DAMAGE_CLIPS属性 drmModeAtomicAddProperty(req, plane_id, prop_ids[PLANE_FB_DAMAGE_CLIPS], damage_clips);

垂直同步处理：

// 请求VSYNC事件 drmEventContext evctx = { .version = DRM_EVENT_CONTEXT_VERSION, .vblank_handler = vblank_handler, }; drmHandleEvent(fd, &evctx); // 精确帧率控制 struct timespec last_vblank; clock_gettime(CLOCK_MONOTONIC, &last_vblank); while (1) { struct timespec next = last_vblank; next.tv_nsec += 16666667; // 60fps if (next.tv_nsec >= 1000000000) { next.tv_sec++; next.tv_nsec -= 1000000000; } clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next, NULL); // 提交新帧 }

硬件加速集成：

// 通过DMA-BUF共享缓冲区 int dma_buf_fd; drmPrimeHandleToFD(fd, gem_handle, DRM_CLOEXEC, &dma_buf_fd); // EGL集成示例 EGLImageKHR image = eglCreateImageKHR(display, EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, NULL, attrs); glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image);

实际测试数据显示优化效果：

场景	FB框架CPU占用	DRM优化后CPU占用
静态界面	15%	3%
60fps动画	75%	12%
视频播放+UI叠加	不可行	25%

5. 常见问题解决手册

问题1：模式设置失败

解决方案：

检查drmModeSetCrtc返回值
验证EDID数据是否正确
使用modetest工具测试原始模式

modetest -M stm -s 28:1280x720@60

问题2：内存泄漏排查

关键检查点：

// 确保释放所有GEM对象 drmModeRmFB(fd, fb_id); drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &dumb); // 使用DRM_IOCTL_GEM_CLOSE关闭handle struct drm_gem_close args = { .handle = gem_handle }; drmIoctl(fd, DRM_IOCTL_GEM_CLOSE, &args);

问题3：多线程安全

最佳实践：

每个线程使用独立的drm文件描述符
原子操作确保状态一致性
使用DRM_MODE_ATOMIC_NONBLOCK避免死锁

pthread_mutex_lock(&display_mutex); drmModeAtomicCommit(fd, req, DRM_MODE_ATOMIC_NONBLOCK, NULL); pthread_mutex_unlock(&display_mutex);

问题4：设备树配置

典型错误排查：

// 检查clock配置 assigned-clocks = <&rcc LTDC_PX>; assigned-clock-parents = <&pll3_r>; assigned-clock-rates = <125000000>; // 验证时序参数 hactive = <800>; vactive = <480>; hfront-porch = <40>; hback-porch = <40>; hsync-len = <48>; vfront-porch = <13>; vback-porch = <29>; vsync-len = <3>;

从FB到DRM的转变不仅是技术栈的升级，更是开发思维的转变。记得第一次成功实现60fps流畅动画时，那种突破技术瓶颈的喜悦至今难忘。DRM的学习曲线确实陡峭，但一旦掌握，就能解锁嵌入式显示的完整能力。建议从简单的modetest工具开始，逐步深入理解KMS的每个组件，最终你会发现自己再也回不去FB的时代了。

查看全文

http://www.cnnetsun.cn/news/2916409.html