Comprender los controladores de dispositivo Linux de la cámara web

11

Hasta donde yo sé, el controlador de dispositivo es una parte de SW que puede comunicarse con un tipo particular de dispositivo que está conectado a una computadora.

En el caso de una cámara web USB, el controlador responsable es UVC que admite cualquier dispositivo compatible con UVC. Esto significa que permite que el sistema operativo u otro programa de computadora acceda a las funciones de hardware sin necesidad de conocer detalles precisos del hardware que se está utilizando.

Por esta razón, instalé el controlador de dispositivo UVC Linux ejecutando:

opkg install kernel-module-uvcvideo

Webcam ha sido reconocido por el kernel de Linux: dev/video0. Sin embargo, todavía no podía realizar la transmisión de video con FFmpeg, ya que me faltaba la API V4L2. Instalé V4L2, configurando el núcleo.

Mis consultas son:

  • ¿Cómo se unen el controlador UVC y el V4L2?
  • ¿Cuál es el propósito de la API V4L2?
  • Si no instalé UVC primero, ¿se instalaría con V4L2?

LinuxTV se refiere: la implementación del controlador uvcvideo es adherente solo a la API V4L2 . ¿Esto significa que UVC es parte de la API V4L2?

linux drivers camera v4l dempap
fuente

Respuestas:

7

La clase de video USB (UVC) es una especificación a la que se supone que se ajustan las cámaras web USB, etc. De esta forma, se pueden usar en cualquier sistema que implemente soporte para dispositivos compatibles con UVC.

V4L2 es el subsistema de video del kernel de Linux del cual depende la implementación de UVC de Linux. En otras palabras, en el núcleo, la compatibilidad con UVC requiere V4L2, pero no al revés.

La API V4L2 se refiere a una interfaz de programación de espacio de usuario , documentada aquí .

encerrada dorada
fuente
Si entendí, el kernel sin V4L2 no puede soportar dispositivos compatibles con UVC, incluso si el controlador uvc está instalado.
Dempap
2
Si. Los controladores son parte del núcleo; aunque pueden compilarse como módulos separados, estos se compilan utilizando una fuente del núcleo. Si esa no es la misma versión de origen que su núcleo en ejecución, no funcionarán, y si no se compilan desde la misma configuración, puede haber inconsistencias significativas. Por ejemplo, si no tiene el núcleo de sonido (ALSA) integrado en el núcleo (o disponible como módulo), entonces un controlador de hardware modular para una tarjeta de sonido es inútil.
Ricitos
13

Es sorprendente la cantidad de documentación que puede encontrar para Video4Linux2, y nada de eso explica qué es Video4Linux .

Primero, Video4Linux2 es un marco de controlador de Linux . Los controladores de framework no controlan los dispositivos directamente. En cambio, proporcionan un modelo abstracto de alguna clase de dispositivo, en este caso dispositivos de video para que las aplicaciones los usen. Los marcos de controladores proporcionan tres beneficios principales:

  1. Proporcione una API unificada para que las aplicaciones las utilicen con una amplia gama de dispositivos físicos, ya sea que estén conectados por USB, PCIe, MIPI, Ethernet u otro tipo de bus de transporte de datos
  2. En el núcleo, los marcos contienen el tipo de código que se necesita en casi todos los controladores de dispositivo de una clase en particular, lo que reduce en gran medida el volumen de código disparejo.
  3. En el núcleo, los marcos proporcionan un plan para escribir nuevos controladores de nivel inferior que realmente controlan el hardware, lo que simplifica el desarrollo de controladores.

Entonces, el controlador V4L2 es un controlador de alto nivel que maneja el controlador UVC, que maneja el controlador USB que podría estar manejando un controlador de hardware de nivel aún más bajo.

Este modelo de Matryoshka es muy común en el árbol de controladores del kernel de Linux. V4L2 es uno de los ejemplos más complejos porque algunos dispositivos de cámara requieren acceder a grandes grupos de subdispositivos en varias capas que controlan la cámara y enrutan la salida de la cámara entre varios componentes, como los procesadores de imágenes.

Todavía puede acceder al controlador UVC directamente desde el espacio de usuario utilizando un archivo de dispositivo y llamadas al sistema "ioctl", sin pasar por el controlador V4L2, y aún puede acceder al controlador USB subyacente directamente desde el espacio de usuario utilizando su archivo de dispositivo y "ioctl" s.

Al ser un marco general que proporciona una funcionalidad común a una amplia gama de dispositivos, V4L2 no le brinda toda la funcionalidad que el controlador UVC podría proporcionar (suponiendo que su dispositivo realmente proporcione más funcionalidad UVC de la necesaria para admitir V4L2) .

Entonces, si tuviera un dispositivo UVC que proporcione todas las funciones especificadas en la especificación UVC, entonces para usar algunas de estas funciones necesitaría acceder al controlador UVC directamente a través de un archivo de dispositivo y un sistema "ioctl" llamadas, suponiendo que el controlador UVC del kernel de Linux de hecho sea compatible con todas las especificaciones UVC.

Sin embargo, el significado de

La implementación del controlador uvcvideo es adherente solo a la API V4L2

es que en el actual controlador LinuxC del núcleo de Linux, de hecho, no proporciona más soporte para la función UVC de la necesaria para V4L2.

El soporte V4L2 en el kernel por sí solo no proporciona soporte UVC o USB o soporte de hardware USB de nivel inferior.

Jonathan Ben-Avraham
fuente