第三章 帧缓冲(Framebuffer)原理

帧缓冲，说白了就是一块内存区域。它专门用来存放显示数据。你想想看，屏幕上每一个像素点的颜色值，最终都要有个地方存着。这个地方，就是帧缓冲。

我刚开始接触嵌入式显示驱动时，总觉得这个概念很抽象。后来亲手调过一块4.3寸屏，才真正理解——帧缓冲就是显存，显存就是帧缓冲。嗯，就是这么简单。

3.1 帧缓冲的核心概念

帧缓冲（Framebuffer）是Linux内核提供的一种显示驱动接口。它屏蔽了底层硬件的差异，让上层应用可以直接操作显示缓冲区。

我个人习惯把帧缓冲理解成「画板」。你在画板上画什么，屏幕就显示什么。画板本身是一块连续的内存区域，每个像素点对应若干字节。

举个例子。假设屏幕分辨率是800×480，颜色深度是32位（RGBA）。那么一帧图像需要的空间是：

800 × 480 × 4 = 1,536,000 字节 ≈ 1.46 MB

这个计算很简单。但我在项目中遇到过一个问题——有些开发板的内存带宽不够，导致高分辨率下刷屏卡顿。所以选型时一定要算好带宽。

3.2 显存映射机制

显存映射，就是把物理显存映射到用户空间的虚拟地址。这样应用程序就能直接读写显存了。

为什么会需要映射？因为内核空间和用户空间是隔离的。你不能在用户态直接访问物理地址。mmap系统调用就是干这个活的。

我记得第一次调帧缓冲驱动时，用mmap映射完显存，然后直接往里面写像素数据。屏幕瞬间亮了。那种感觉，怎么说呢，很有成就感。

映射的典型流程如下：

1. 打开帧缓冲设备文件（/dev/fb0）
2. 通过ioctl获取屏幕参数（分辨率、位深等）
3. 计算显存大小
4. 调用mmap映射显存到用户空间
5. 直接操作映射后的内存地址

代码示例：

int fd = open("/dev/fb0", O_RDWR);
struct fb_var_screeninfo vinfo;
ioctl(fd, FBIOGET_VSCREENINFO, &vinfo);

// 计算显存大小
size_t screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;

// 映射显存
char *fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, 
                         MAP_SHARED, fd, 0);

// 直接写像素
*(unsigned int *)(fbp + offset) = 0x00FF0000;  // 红色

munmap(fbp, screensize);
close(fd);

3.3 双缓冲机制

双缓冲，说白了就是准备两个缓冲区。一个用于显示（前台缓冲），一个用于绘制（后台缓冲）。

为什么要搞两个？因为单缓冲会有闪烁问题。你想想看，如果直接在显示缓冲区里画图，画到一半时屏幕刷新了，用户就会看到半成品。这就是撕裂（tearing）。

双缓冲的工作流程是这样的：

• 后台缓冲：应用程序在这里绘制下一帧画面
• 前台缓冲：当前正在显示的内容
• 交换操作：绘制完成后，交换前后台缓冲的指针

我建议在驱动层实现双缓冲时，注意两个关键点：

1. 缓冲区大小必须一致。否则交换时会出现错位。
2. 交换时机要选在垂直消隐期（VBlank）。这样可以避免撕裂。

双缓冲的内存布局：

物理显存地址空间：
+------------------+
| 前台缓冲 (FB0)   |  ← 当前显示
+------------------+
| 后台缓冲 (FB1)   |  ← 正在绘制
+------------------+

交换操作不是真的拷贝数据，而是修改显示控制器的起始地址指针。这样效率极高，几乎是零开销。

3.4 实际项目中的经验

讲几个我在实际项目中踩过的坑：

• 内存对齐问题：有些LCD控制器要求帧缓冲地址按4KB对齐。不对齐的话，显示会花屏。
• 缓存一致性：ARM架构下，CPU写显存时可能只写到Cache里。需要手动flush Cache，否则DMA读到的还是旧数据。
• 多图层叠加：现代显示控制器支持多个图层。每个图层都有自己的帧缓冲。我建议把图层0留给UI，图层1留给视频，这样管理起来清晰。

嗯，这一章就讲到这里。下一章我们会深入聊聊像素格式和颜色空间。到时候我会分享一个关于颜色校正的实战案例，挺有意思的。