Class：Class，Class与Class工作原理：USBClass

关于UVC设备有两个/dev/video*节点的原因和起源？ 专栏 - CSDN博客 在.04/.04系统上，插入UVC设备，你会发现V4L2框架为其创建了两个视频设备节点，分别是/dev/、/dev/：

USB Video Class及其实现专栏 - CSDN博客1 Video Class的基本概念 USB协议除了通用的软硬件电气接口规范外，还包含多种Class协议，用于为不同的功能定义各自的协议。 标准接口和特定总线上的数据交换格式和内容。 这些Class协议有很多，最常见的是支持U盘功能的Mass Class，以及通用数据交换协议：CDC类。 此外，还包括Audio Class、Print Class等。理论上，即使没有这些类，也可以通过专用驱动程序来实现各种应用功能。 然而，作为大众S...

UVC 的工作原理：

关于UVC的实现，UVC驱动分为设备端和主机端。 根据Linux内核的实现来看，设备端实现源端的版本信息描述为“USB Video Class”，而主机端实现为“USB Video Class”。并且无论是主机端还是主机端设备连接到v4l2框架，如下图所示。

UVC设备驱动初始化入口是

主机端驱动初始化入口是。 至于为什么这么肯定是主机端驱动，是因为linux//meida/usb/uvc/目录的编译依赖于SS宏配置，而这个宏配置是主机的一个配置项侧驱动程序。 。

注册 /dev/video 设备节点用于发送：

主机也有一个相同的接口：

主机端注册IOCTL

与主机端相反，这里正在将编码帧发送到 USB 接口，而 dqbuf 正在获取空帧。

它也会被调用，在 USB 传输完成后生成一个空帧。

传输完成后，USB协议栈调用接口

通过接口，调用，返回空帧给V4L2

这样看来，作为设备端的UVC驱动和作为主机端的UVC驱动的语义是一样的，只是数据流向相反。 在主机端，dqbuf是有用的像素数据，qbuf是空帧，即帧数据，在设备端，qbuf是有效编码数据，必须通过USB发送，dqbuf是空帧，表示USB传输做完了。 这个可以重新填充，就是无效数据，所以正好是相反的过程。

换句话说，/dev/节点可以用作输入源或输出接收器。 用户级可以通过/dev/发送数据，它在这两种情况下的用途和作用恰恰是双重的。

UVC驱动分为主机端和设备端的另一个铁证就是调用描述。 在使用V4L2设备之前，应用程序一般会调用检测视频设备。 返回的主要函数有两个。 一是

/RE，代表UVC主机驱动，捕获数据流的能力，比如PC主机UVC驱动连接到UVC相机。

当然还有另一个，T，代表视频。 设备节点可以输出视频帧，对应UVC设备驱动，如UVC相机驱动。

有关其他UVC相机的信息，请参考博客：

科技IPC相机试用专栏-CSDN博客IPC详细参数如下： 闪烁控制：50HZ、60HZ 图片格式：Bmp、jpg。 传感器格式：CMOS 支持等视频会议软件 180M/bmp告诉处理器 接口类型：USB2.0 内置：吸音降噪麦克风 分辨率：/描述符信息::@--3268:~$ lsusb -d 0c45:64ab -vBus 001 011：ID 0c45:64

配置：

如果要支持UVC设备端功能，需要打开以下配置项：

手动的：

对于UVC设备端应用，系统中有两种类型的UVC设备。 一种是V4L2设备，负责连接摄像头采集图像，另一种是V4L2设备，通过USB发送压缩格式图像。 出去。 中间通过用户层软件连接，用户软件的功能主要是进行编码操作。

对模块建立宏观印象的最佳方法是查看应用程序如何使用它。 我们来看一下UVC设备的具体应用实现：

总结：

在运行Linux-4.15或更高版本内核的主机上，如果插入USB摄像头，会出现两个/dev/video*。 这不是一个bug，而是V4L2的一个特性。 更多讨论请参阅这篇文章：

– V4L2 每个两个视频

在阅读UVC实现框架代码时，您可以比较主机端和设备端驱动程序，以便更好地理解整个路径。

关于UVC相机连接的主机通道的配置，请参考：

UVC驱动的实现框架如下图所示：

结束！