转载于：　http://blog.csdn.net/lizuobin2/article/details/53006927

本文基于：linux3.5

前面一篇文章中，简单分析了 V4L2 大框架，本文借助内核中的虚拟摄像头驱动 vivi 来分析一个完整的摄像头驱动程序。vivi 相对于后面要分析的 usb 摄像头驱动程序，它没有真正的硬件相关层的操作，也就是说抛开了复杂的 usb 层的相关知识，便于理解 V4L2 驱动框架，侧重于驱动和应用的交互。

前面我们提到，V4L2 的核心是 v4l2-dev.c 它向上提供统一的文件操作接口 v4l2_fops ，向下提供 video_device 注册接口 register_video_device ，作为一个具体的驱动，需要做的工作就是分配、设置、注册一个 video_device.框架很简单，复杂的是视频设备相关众多的 ioctl。

一、vivi 框架分析

vivi 分配了一个 video_device 指针，没有去设置而是直接让它指向了一个现成的 video_device 结构 vivi_template ，那么全部的工作都将围绕 vivi_template 展开。

用户空间调用的是 v4l2_fops ，但是最终会调用到 vivi_fops ，vivi_fops 中的 ioctl 调用 video_ioctl2

video_register_device 过程就不详细分析了，前面的文章中分析过，大概就是向核心层注册 video_device 结构体，核心层注册字符设备并提供一个统一的 fops ，当用户空间 read write ioctl 等，最终还是会跳转到 video_device->fops ,还有一点就是核心层会把我们注册进来的 video_device 结构放入一个全局的 video_device数组。

这里，先看一下 v4l2_fh_open 函数

1、我们随时可以通过 video_devdata 取出我们注册的 video_device 结构进行操作

2、我们随时可以通过 file->private_data 取出 v4l2_fh 结构，虽然现在还不知道它有啥用

下面来分析 ioctl ...首先来看一下调用过程

vivi 驱动就复杂在这些 ioctl 上，下面按照应用层与驱动的交互顺序来具体的分析这些 ioctl 。

二、ioctl 深入分析

应用空间的一个视频 app 与驱动的交互流程大致如下图所示：

2.1 VIDIOC_QUERYCAP 查询设备能力

应用层：

驱动层：

一般我们只关心 capabilities 成员，比如V4L2_CAP_VIDEO_CAPTURE 具有视频捕获能力，其它定义如下：

2.2 VIDIOC_ENUM_FMT 枚举(查询)设备支持的视频格式

应用层：

驱动层：

一般一个设备支持多种视频格式，比如 vivi 它所支持的格式存放在 formats 数组中，由于应用层并不知道设备支持多少种格式，也不知道某种格式具体存放在哪个数组项中，因此通过index从0开始尝试，对于驱动层来说就是遍历所有的数组项，返回每一个index对应的视频格式，比如 V4L2_PIX_FMT_YUYV .

2.3 VIDIOC_S_FMT 设置视频格式

应用层：

驱动层：

这里将应用层传进来的视频格式简单处理后存放进了一个 vivi_dev 结构，vivi_dev 哪里来的呢？，在一开始的时候 vivi_create_instance ,我们创建了一个 video_device 结构代表我们的设备，并设置了一个 vivi_dev 作为 video_device->dev->privatedata ，之后 register_video_device ，内核会自动将我们的 video_device 放入全局数组 video_device[] 中。

2.4 VIDIOC_G_FMT 获得设置好的视频格式

应用层：

驱动层：

将我们之前设置的格式返回而已。
  2.5 VIDIOC_REQBUFS 请求在内核空间分配视频缓冲区
    分配的内存位于内核空间,应用程序无法直接访问,需要通过调用mmap内存映射函数,把内核空间的内存映射到用户空间,应用才可以用用户空间地址来访问内核空间。
应用层：

驱动层：

vb_vidq 是 vivi_dev 的一个成员，前面我们提到它有两个 ops ，一个是 ops 另一个是 mem_ops

2.6 VIDIOC_QUERYBUF 查询分配好的 buffer 信息
    查询已经分配好的V4L2视频缓冲区的相关信息,包括缓冲区的使用状态、在内核空间的偏移地址、缓冲区长度等,然后应用程序根据这些信息使用mmap把内核空间地址映射到用户空间。
应用层：

驱动层：

2.7 mmap
应用层：

驱动层：

2.8 VIDIOC_QBUF 
  投放一个空的视频缓冲区到视频缓冲区输入队列，执行成功后，在启动视频设备拍摄图像时，相应的视频数据被保存到视频输入队列相应的视频缓冲区中。
应用层：

驱动层：

实质上就是取出一个 vb2_buffer 挂入 vivi_dev->vb_vidq->queued_list
2.9 VIDIOC_STREAMON
应用层：

驱动层：

每次调用 vivi_sleep 这个线程都被挂入等待队列，调用 vivi_thread_tick 填充数据，然后休眠指定的时间自动唤醒，一直循环下去。这样就生成了一帧一帧的视频数据。

开始的时候我们将以一个 vb_buffer 挂入 vb_vidq->queued_list ，当启动视频传输之后，它被取出挂入
vb_vidq->vidq->active 队列，然后在内核线程中每一个 tick ，又将它取出填充视频数据之后，再挂入
vb_vidq->done_list ，唤醒正在休眠等待视频数据的应用程序。
2.10 select
驱动层：

唤醒之后，我们就可以去从视频输出队列中取出buffer，然后根据映射关系，在应用空间取出视频数据了
2.11 VIDIOC_DQBUF
应用层：