1、课程导论：为什么需要从FB迁移到DRM？

各位同学好，我是老李。做Linux显示驱动这块有些年头了。今天咱们聊聊一个绕不开的话题——为什么要把老掉牙的Framebuffer（FB）框架，迁移到DRM（Direct Rendering Manager）上来。

说实话，我刚入行那会儿，FB框架还是主流。那时候觉得，能点亮屏幕、能显示个Logo，就挺满足的。但后来项目越做越复杂，FB的坑一个接一个地冒出来。嗯，今天就把这些经验掰开了讲。

1.1 FB框架的局限性——我踩过的那些坑

FB框架，全称Linux Framebuffer，是内核里最早的一套显示框架。它的设计思路很简单：给你一块内存区域，你把像素数据填进去，它负责显示出来。听起来挺直接，对吧？但实际用起来，问题不少。

我总结了几条FB框架的硬伤，你看看是不是也遇到过：

问题	具体表现	我在项目中遇到的真实案例
单缓冲限制	不支持Page Flip（页面翻转），只能单缓冲操作，容易产生撕裂（tearing）	做车载仪表盘时，指针刷新总有撕裂线，客户投诉了好几次
无硬件图层合成	所有图层必须在用户态用CPU合成，再传给FB，效率极低	做视频播放器时，CPU占用率飙到80%，机器烫得能煎鸡蛋
不支持多显示器	一个FB设备只能对应一个显示输出，多屏扩展需要额外驱动	做双屏收银机时，两个屏幕各用各的FB，同步问题让人崩溃
缺少VSync同步	没有标准的垂直同步机制，刷新时机不可控	做游戏机模拟器时，画面撕裂和跳帧成了常态
用户态接口简陋	只有简单的ioctl操作，没有统一的API管理	每次换芯片平台，用户态代码几乎要重写
无GPU/硬件加速集成	FB本身不提供GPU交互接口，加速全靠自己拼	做3D UI时，OpenGL和FB之间来回切换，性能损失很大

说白了，FB框架就像一个只能写字的黑板。你想画个彩色插图？可以，但得自己调颜料、自己画，而且一次只能画一张。DRM呢，就像给你一套完整的画室——有画架、有调色板、有各种画笔，还能同时画好几幅画。

1.2 DRM框架的优势——为什么我推荐你迁移

DRM（Direct Rendering Manager）是内核里新一代的显示框架。它从设计之初就考虑到了现代显示的需求。我个人觉得，DRM最大的优势在于三点：

1. 硬件抽象做得好——把显示硬件的能力暴露给用户态，而不是替用户做决定
2. 支持现代显示特性——多图层、多显示器、Page Flip、VSync，这些都是原生支持
3. 与GPU生态无缝集成——DRM是Mesa、Wayland、Xorg等图形栈的底层基础

来看看DRM到底强在哪里：

特性	FB框架	DRM框架
缓冲机制	单缓冲，易撕裂	双缓冲/多缓冲，Page Flip原子切换
图层合成	CPU合成，效率低	硬件合成（Overlay/Plane），零拷贝
多显示器	不支持，需额外驱动	原生支持，CRTC+Encoder+Connector模型
垂直同步	无标准接口	VSync事件，精确控制刷新时机
GPU集成	无	GEM/Dumb Buffer，与GPU驱动共享内存
用户态API	ioctl散乱	libdrm统一接口，KMS/DRM两层API
电源管理	基本没有	DPMS、FBC、PSR等节能特性
社区支持	几乎停滞	活跃维护，新特性持续加入

你想想看，DRM为什么能成为主流？原因很简单——它把显示驱动的复杂度，从内核态转移到了用户态。内核只负责最核心的硬件管理，具体的渲染策略、合成方式，交给用户态的图形栈去决定。这种分层设计，让整个系统更灵活、更可扩展。

1.3 迁移路线图概览——从FB到DRM，我们怎么走？

好了，既然FB有这么多问题，DRM又这么好，那怎么迁移呢？别急，我画了一张迁移路线图，帮你理清思路。

这张图是我在实际项目中总结出来的迁移路径。你看，整个流程分6个阶段：

• 阶段1：评估与规划——先搞清楚你的硬件支持哪些DRM特性，现有FB驱动有多少代码可以复用。我建议你花一周时间做这个评估，别急着动手。
• 阶段2：基础驱动——搭建DRM/KMS框架，实现最基本的CRTC（显示控制器）和Encoder（编码器）。这一步能点亮屏幕就算成功。
• 阶段3：功能完善——添加多图层支持、实现Page Flip。这是DRM相比FB的核心优势，值得花时间打磨。
• 阶段4：性能优化——VSync精确控制、FBC（帧缓冲压缩）、PSR（面板自刷新）等节能特性。这一步能让你的驱动从“能用”变成“好用”。
• 阶段5：用户态集成——封装libdrm接口，适配Wayland或Xorg。这一步决定了你的驱动能不能被上层应用正常调用。
• 阶段6：测试与验证——功能测试、性能基准对比。我建议你保留一份FB驱动的测试数据，迁移前后做个对比，这样能直观看到DRM的优势。

1.4 为什么现在必须迁移？

你可能觉得，FB框架还能用，为什么要折腾？我跟你讲几个现实原因：

• 内核社区已经停止FB驱动的维护——新的内核版本对FB的支持越来越少，bug没人修，新特性没人加。你想想看，用一套没人维护的框架，风险有多大？
• 主流图形栈已经全面转向DRM——Wayland、Xorg、Mesa、Qt、GTK，这些图形栈的底层都是基于DRM的。你用FB，就等于把自己隔离在主流生态之外。
• 硬件厂商只提供DRM驱动——现在新出的SoC和GPU，厂商只提供DRM驱动。你想用FB？对不起，自己写。我去年做一个项目，用的RK3588芯片，厂商只给了DRM的BSP，FB驱动？想都别想。
• 性能差距越来越大——DRM的硬件图层合成、Page Flip、VSync这些特性，FB一个都没有。在4K、8K、高刷新率的场景下，FB根本跑不动。