1. V4L2框架全景：从驱动到应用
做嵌入式多媒体开发这些年，我接触过不少采集方案。从早期的摄像头直读到现在的复杂ISP流水线，V4L2始终是Linux生态里绕不开的核心。说白了，它就是一套标准化的视频采集接口——不管你是USB摄像头、MIPI CSI接口的传感器，还是HDMI采集卡，到了应用层，操作方式都差不多。
嗯，这里我们先搞清楚一件事：V4L2在Linux多媒体子系统里到底扮演什么角色？
1.1 Linux多媒体子系统概览
Linux内核的多媒体相关模块，大致可以分成三层：
| 层次 | 组件 | 职责 |
|---|---|---|
| 应用层 | GStreamer、FFmpeg、OpenCV、自定义App | 调用V4L2 API完成采集、编码、显示 |
| 内核框架层 | V4L2核心、V4L2子设备、Media Controller、VB2 | 提供统一的设备模型和IO机制 |
| 硬件驱动层 | Sensor驱动、ISP驱动、DMA引擎、显示驱动 | 直接操作寄存器，控制硬件行为 |
V4L2就卡在中间这一层。它向上给应用提供open/ioctl/mmap/poll这些标准接口，向下通过内核框架与具体硬件驱动交互。我刚开始做驱动时，总觉得这层抽象是多余的——直接操作硬件多痛快？后来产品要换Sensor，我才明白V4L2的价值：驱动接口不变，应用代码一行都不用改。
1.2 V4L2核心架构
V4L2的核心设计思想，我总结为四个字：设备抽象。它把复杂的视频硬件抽象成几个标准设备节点：
- video节点（/dev/videoX）：主数据通道，负责帧的采集和输出
- v4l-subdev节点（/dev/v4l-subdevX）：子设备接口，控制Sensor、ISP等模块
- media节点（/dev/mediaX）：Media Controller拓扑管理，用于复杂pipeline
你想想看，一个典型的嵌入式摄像头模组，内部可能有Sensor、ISP、MIPI桥接芯片三个硬件。如果没有V4L2，应用层得分别操作三个设备，还要自己协调时序。有了V4L2，应用只需要打开一个video节点，剩下的路由和同步，驱动层帮你搞定。
核心要点：V4L2不是某个具体的驱动，而是一套框架。它定义了驱动该实现哪些回调、应用该调用哪些ioctl、数据该用什么方式传递。理解了这个，你才能用好它。
1.3 V4L2框架全景图
下面这张图，是我画了无数遍才定稿的。它展示了V4L2从硬件到应用的完整数据流：
这张图里，我特意把VB2和子设备框架单独画出来了。为什么？因为这两个模块是V4L2性能优化的关键。VB2负责buffer的申请、入队、出队和回收，它直接决定了帧率的上限。子设备框架则管理着Sensor、ISP这些内部模块的联动——我在调试一个4K采集项目时，发现帧率上不去，最后定位到是子设备之间的同步没配好。
1.4 关键数据结构
V4L2驱动开发，说白了就是跟几个核心结构体打交道。我列个清单：
| 结构体 | 所在文件 | 作用 |
|---|---|---|
struct video_device |
media/v4l2-dev.h | 代表一个V4L2设备节点，注册到内核 |
struct v4l2_device |
media/v4l2-device.h | 顶层V4L2设备实例，管理子设备 |
struct v4l2_subdev |
media/v4l2-subdev.h | 子设备抽象，Sensor/ISP都挂在这里 |
struct vb2_queue |
media/videobuf2-core.h | VB2缓冲队列，管理所有buffer |
struct vb2_buffer |
media/videobuf2-core.h | 单个buffer的描述，含内存信息 |
struct media_device |
media/media-device.h | Media Controller拓扑描述 |
我记得第一次写V4L2驱动时，光搞清楚video_device和v4l2_device的关系就花了两天。简单说：一个v4l2_device可以挂多个video_device（比如一个采集、一个输出），每个video_device又关联一个vb2_queue。子设备则通过v4l2_subdev注册到父设备上。
1.5 应用层视角：ioctl调用流程
从应用层看V4L2，其实就是一套ioctl命令。典型的采集流程是这样的：
- 打开设备：
fd = open("/dev/video0", O_RDWR) - 查询能力：
ioctl(fd, VIDIOC_QUERYCAP, &cap)，确认设备支持采集 - 设置格式：
ioctl(fd, VIDIOC_S_FMT, &fmt)，指定分辨率、像素格式 - 申请buffer：
ioctl(fd, VIDIOC_REQBUFS, &req)，分配帧缓冲 - 查询并映射buffer：
ioctl(fd, VIDIOC_QUERYBUF, &buf)+mmap() - 入队buffer：
ioctl(fd, VIDIOC_QBUF, &buf)，把空buffer交给驱动 - 启动采集：
ioctl(fd, VIDIOC_STREAMON, &type) - 等待数据：
poll(fd, ...)或select() - 出队已填满的buffer：
ioctl(fd, VIDIOC_DQBUF, &buf) - 处理数据：从mmap地址读取帧数据
- 重新入队：
ioctl(fd, VIDIOC_QBUF, &buf)，循环
个人经验：很多新手在VIDIOC_REQBUFS这一步踩坑。申请buffer数量不是越多越好——我见过有人申请32个，结果内存爆了。嵌入式设备一般4~6个就够，既能保证流水线不空转，又不浪费宝贵的内存。
1.6 驱动层视角：回调函数实现
驱动开发者要实现的，是V4L2框架定义的一组回调。核心的包括：
// VB2队列操作回调
static int queue_setup(struct vb2_queue *q,
unsigned int *nbuffers,
unsigned int *nplanes,
unsigned int sizes[],
struct device *alloc_devs[]);
static int buffer_prepare(struct vb2_buffer *vb);
static int buffer_queue(struct vb2_buffer *vb);
static int start_streaming(struct vb2_queue *q, unsigned int count);
static int stop_streaming(struct vb2_queue *q);
// V4L2 ioctl回调
static const struct v4l2_ioctl_ops my_ioctl_ops = {
.vidioc_querycap = my_querycap,
.vidioc_s_fmt_vid_cap = my_s_fmt_vid_cap,
.vidioc_enum_fmt_vid_cap = my_enum_fmt_vid_cap,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
};这里有个细节：vb2_ioctl_reqbufs这些函数是VB2框架帮你实现的，你只需要实现底层的queue_setup、buffer_prepare等回调。我曾经犯过一个错误——在start_streaming里忘了使能DMA中断，结果应用层一直poll不到数据，排查了整整一个下午。
1.7 为什么需要Media Controller？
早期的V4L2驱动，一个video节点对应一个硬件设备，简单直接。但现在的摄像头模组越来越复杂——Sensor输出RAW，经过ISP处理，再送到MIPI CSI接收器，最后进内存。如果每个模块都独立注册一个video节点，应用层得自己拼图，太痛苦了。
Media Controller就是来解决这个问题的。它通过/dev/mediaX节点暴露内部的pipeline拓扑，应用可以用MEDIA_IOC_ENUM_LINKS和MEDIA_IOC_SETUP_LINK来动态配置数据路径。
避坑指南：我曾经在一个项目中，Sensor输出是10-bit RAW，但ISP只接受8-bit。因为没有配好Media Controller的link，数据直接传过去，画面全是噪点。后来加上格式转换实体，才搞定。记住：Media Controller不只是拓扑管理，它还负责格式协商。
1.8 本章小结
V4L2框架的核心价值，在于它把千差万别的视频硬件抽象成统一的接口。无论你用的是哪家Sensor、哪种总线，到了应用层，都是open/ioctl/mmap/poll这一套。作为驱动开发者，你的任务就是实现V4L2定义的回调，把硬件能力映射到框架里。
嗯，这一章先到这里。后面的章节，我们会深入VB2缓冲管理、DMA优化、帧率调优这些实战内容。到时候我会拿实际项目中的代码和踩坑记录来讲解，比纯理论有意思得多。