3. 显示驱动框架：Linux DRM/KMS架构、Framebuffer机制、双屏独立渲染原理
好，咱们进入第三个核心话题。显示驱动这块，说实话，是双屏异显项目里最容易出幺蛾子的地方。很多朋友一上来就撸应用层代码，结果发现第二个屏幕死活点不亮，或者两个屏显示一模一样——嗯，这就是没搞懂底层驱动框架。
我个人习惯，做双屏项目前，先把Linux显示驱动栈理一遍。你想想看，底层都不通，上层再花哨也是白搭。
3.1 Linux DRM/KMS架构——显示系统的“交通管制中心”
DRM，全称Direct Rendering Manager，直接渲染管理器。KMS，Kernel Mode Setting，内核模式设置。这两个东西合在一起，就是Linux下现代显示驱动的标准框架。
说白了，DRM/KMS就是内核里负责管理显示资源的那一套机制。它管什么？管显存分配、管屏幕分辨率、管刷新率、管图层叠加。你上层调一个ioctl，底层就帮你把硬件寄存器配好。
我在项目中遇到过一件事：有个同事自己写了一个framebuffer驱动，绕开DRM直接操作寄存器。结果换了一个内核版本，驱动直接崩了。为什么？因为内核的显示资源管理机制变了，你绕开它，它就不认你。
核心要点：DRM/KMS是Linux显示驱动的标准接口。做双屏异显，必须走DRM/KMS这条路。别自己造轮子，轮子已经有人造好了。
DRM架构里，有几个关键概念你得记住：
- CRTC：显示控制器。每个CRTC对应一个独立的显示通道。双屏就需要两个CRTC。
- Encoder：编码器。把CRTC输出的信号转换成某种接口标准，比如HDMI、DP、LVDS。
- Connector：连接器。物理接口，比如你插HDMI线那个口子。
- Plane：图层。每个CRTC可以叠加多个图层，比如一个视频层、一个UI层。
你看，一个完整的显示链路就是：CRTC → Encoder → Connector → 显示器。双屏异显，就是两条这样的链路同时工作。
3.2 Framebuffer机制——显存里的“画布”
Framebuffer，帧缓冲。这个概念其实很老了，但至今仍然在用。它本质上就是一段内存区域，用来存放一帧图像的数据。CPU或者GPU把图像数据写进去，显示硬件定时从里面读出来，刷新到屏幕上。
在DRM框架下，Framebuffer是通过drm_framebuffer对象来管理的。你创建一个Framebuffer，其实就是分配一块显存，然后告诉内核：这块显存对应哪个CRTC、哪个Plane。
我记得刚开始做嵌入式显示时，总以为Framebuffer就是直接映射到屏幕上的。后来才发现，没那么简单。Framebuffer只是一个数据容器，它和屏幕之间还有一层“扫描”机制。硬件DMA会周期性地从Framebuffer里取数据，然后发送给显示器。
小技巧：调试Framebuffer时，可以用cat /dev/fb0 > screen.raw把当前屏幕内容dump出来。然后用ffplay -f rawvideo -pixel_format rgb565 -video_size 1024x600 screen.raw查看。这招我用了好多年，排查显示异常特别管用。
Framebuffer有几个关键参数：
| 参数 | 说明 | 常见值 |
|---|---|---|
| bits_per_pixel | 每个像素占多少位 | 16（RGB565）、32（ARGB8888） |
| width/height | 分辨率 | 1024x600、1920x1080 |
| stride | 一行数据占多少字节 | 通常 = width * bpp / 8，但可能有对齐要求 |
| size | 整个Framebuffer大小 | stride * height |
这里有个坑：stride不一定等于width乘以像素字节数。有些硬件要求每行数据按16字节或32字节对齐。你如果按width直接算，写数据时就会错位。我曾经在这个问题上折腾了两天，画面一直撕裂错位，最后发现是stride没对齐。
3.3 双屏独立渲染原理——两个画师各画各的
双屏独立渲染，说白了就是两个屏幕各自拥有独立的Framebuffer，各自独立刷新。一个屏显示导航地图，另一个屏显示仪表盘，互不干扰。
原理上其实不复杂：
- 系统初始化时，检测到两个显示器，分别对应两个Connector。
- 为每个Connector分配一个CRTC，每个CRTC绑定一个独立的Framebuffer。
- 上层应用分别往两个Framebuffer里写数据。
- 硬件定时从两个Framebuffer里取数据，分别发送给对应的显示器。
你想想看，这就像两个画师，各拿一块画板，各画各的。画板之间没有共享，所以内容完全独立。
代码层面，核心操作就是：
// 伪代码：双屏独立渲染
// 屏幕0
struct drm_framebuffer *fb0 = drm_framebuffer_create(drm_fd, width0, height0, format);
drm_mode_set_crtc(drm_fd, crtc0, fb0->id, connector0_id, mode0);
// 屏幕1
struct drm_framebuffer *fb1 = drm_framebuffer_create(drm_fd, width1, height1, format);
drm_mode_set_crtc(drm_fd, crtc1, fb1->id, connector1_id, mode1);
// 分别渲染
render_navigation(fb0); // 导航屏
render_dashboard(fb1); // 仪表屏这里有个关键点：两个Framebuffer是独立的，所以两个屏幕的分辨率、刷新率、色彩格式都可以不一样。主屏1920x1080@60Hz，副屏800x480@30Hz，完全没问题。
注意：双屏独立渲染不等于双屏内容完全无关。有些场景下，两个屏需要显示关联信息，比如仪表盘显示导航提示。这时候就需要进程间通信或者共享内存来同步数据。但渲染过程本身是独立的。
我在实际项目中，遇到过一个问题：两个屏同时刷新时，总带宽超过了硬件限制。比如主屏4K@60Hz，副屏1080p@60Hz，加起来带宽超过了总线的承载能力。结果就是画面闪烁、撕裂。解决办法是降低副屏刷新率，或者用双通道DDR。
嗯，这里要记住：双屏独立渲染，硬件资源是共享的。显存带宽、总线带宽、GPU性能，这些都要提前评估好。别等到板子打回来了才发现跑不动。
最后总结一下：DRM/KMS是框架，Framebuffer是画布，双屏独立渲染就是两个画布各自刷新。搞懂了这三层，双屏异显的底层逻辑你就拿下了。