Meses atrás me había decidido a comprar una webcam para casa. Esto no tiene mucha dificultad a primera vista, salvo por el detalle de ser un usuario de GNU/Linux, lo que hace que uno tenga que buscar el hardware soportado con un poco más de detenimiento. Busqué webcams soportadas por el núcleo Linux, ya sea directamente o por controladores de terceros, comparé con las que estaban disponibles en el mercado y finalmente me decidí a comprar una webcam Genius VideoCam Look 300. Esta cámara tiene soporte oficial desde hace un tiempo en el núcleo, y no tiene reportes de fallos ni de calidad de imagen. Parecía un candidato perfecto.

Compré la webcam, configuré y compilé el núcleo, enchufo la cámara e inicio varios programas para probarla y los resultados no fueron buenos, los colores se veían mal, el controlador no maneja correctamente el led de encendido/apagado (y probablemente la transmisión de datos). No era un buen comienzo. Empiezo a buscar en profundidad sobre la webcam, reviso foros, llego a la página del autor del controlador y veo que vende un controlador que dice que funciona bien y tiene mayor soporte para aplicaciones, gente que tiene los mismos problemas (hace ya más de un año) y que todavía no tiene solución. Nada buena la situación.

En ese momento pensé en tres cosas: devuelvo la webcam (o se la regalo a alguien), espero que se arregle el problema con el driver (muy improbable ya que lleva mucho tiempo sin solución) o intento buscarle una solución yo. Habiendo hecho las opciones 1 y 2 anteriormente con otros dispositivos, elegí encarar y tratar de encontrarle yo la solución. Ahora tenía que investigar que opciones tenía para poder solucionarlo.

Las opciones

Investigando encontré estas opciones para poder hacer el desarrollo del controlador de mi webcam:

1. Corregir el controlador oficial.

2. Escribir el controlador de nuevo, desde 0.

3. Utilizar algún proyecto alternativo.

La primera opción la descarté porque no me gusto la actitud del autor, vi que no tenía mucho contacto con otros desarrolladores y que a todos los que tenían problemas les pedía que usaran su controlador pago. Escribir todo de nuevo era mucho para mi y quería aprovechar que existen proyectos que soportaban cámaras similares a la mia. Los proyectos que me parecieron más adecuados fueron: microdia y GSPCA V4L v2.

Los dos proyectos soportan familias de webcams similares a las mias, de estos dos me quede con el último ya que el primero por ahora tiene soporte para modelos más actuales que mi webcam y GSPCA.

¿Qué es GSPCA?

“Generic Software Package for Camera Adapters” (GSPCA) es una reescritura y limpieza del controlador SPCA5xx, que soporta más de 100 cámaras web. Desde el controlador original ha sufrido muchos cambios y hoy en día es un framework para escribir controladores de webcams USB, donde las cosas comunes a todos los drivers como el manejo de las transferencias USB isocronicas, las negociaciones de configuración para las aplicaciones, la administración de buffers, locking, etc, está a cargo del componente básico de este controlador. Esto permite que los componentes específicos de cada controlador puedan ocuparse de los detalles del bridge y el sensor que cada cámara posee sin tener que detenerse en los otros detalles. Los controladores específicos de los bridges se llaman subcontroladores.

Los controladores de una webcam USB tienen 2 partes igualmente díficiles:

1. Configuración de mensajes USB, administración de interrupciones, administración de buffers entre el núcleo y las aplicaciones, incluyendo sincronizaciones y permitir a multiples aplicaones utilizar la webcam al mismo tiempo. Manejo de conexión/desconexión en caliente.

2. Saber que hay que mandarle a la webcam para que empiece a mandar datos y como procesar los datos recibidos.

El primer punto es algo que es común a todas las webcams USB que no sean UVC (USB Video Class, estándar para dispositivos con capacidades de streaming de video, relativamente nuevo) y es lo que resuelve el núcleo del controlador GSPCA, evitando la duplicación de código y reduciendo la posibilidad de errores.

¿Qué hay que hacer?

Las webcams USB normalmente tienen 2 partes bien diferenciadas y que cumplen funciones especificas, la primera parte es el bridge, que se conecta directamente al bus USB y se conecta al sensor, responsable de la captura del flujo de video. Es común que las bridges estén conectados por un bus I2C al sensor.

Hacer que una webcam funcione correctamente implica:

1. Identificar el bridge y sensor de la webcam.

2. Configurar el bridge, para que nos transfiera datos a través del bus USB cuando lo necesitemos.

3. Configurar el sensor, para obtener un flujo correcto de imagen.

4. Interpretar la información recibida para poder recibir los diferentes cuadros.

¿Cómo podemos hacer para saber todo esto? En algunos casos y si hay suerte, se puede contar con las hojas de datos de los bridges y/o sensores. Otra fuente común es la de otros drivers que tengan soporte para hardware similar. Pero la fuente de información más común para empezar suele ser la obtenida a partir de los controladores provistos por el fabricante para Windows, tanto los archivos de instalación (los archivos *.inf suelen identificar el bridge/sensor de una webcam) como del controlador funcionando.

Existen herramientas que nos permiten capturar el tráfico USB que existe entre la PC y cierto dispositivo y luego analizarlo. Buscando en la documentación de los proyectos se pueden encontrar tutoriales muy fáciles de seguir que explican como hacerlo. También proveen herramientas para procesar la información obtenida y hasta para generar código.

Manos a la obra

Habiendo recopilado toda la información sobre mi webcam, incluyendo capturas de las comunicaciones en Windows, empece a a trabajar. Ya tenía identificados el bridge y el sensor de mi webcam. El primer punto ya estaba completo. Hasta conseguí la hoja de datos del sensor de mi webcam.

El primer paso fue lograr un flujo de imagen constante, fue lo que más trabajo costó ya que el bridge existente en mi webcam no estaba soportado en el subcontrolador y requería un tratamiento diferente al resto de los bridges. En este punto, las capturas del tráfico fueron fundamentales. Tras un par de semanas de intercambio de pruebas, opiniones, consejos y busquedas en internet, el segundo y el cuarto paso ya estaban completos. La webcam mostraba un flujo de imagen continuo.

Quedaba configurar el sensor, esta parte fue un poco más fácil, ya que al apoyo de las capturas, se sumaba la hoja de datos y podía entender claramente que implicaba cada configuración.

En poco tiempo la webcam ya estaba funcionando. No solo estaba haciendo funcionar mi webcam sino aprendiendo como utilizar el framework GSPCA, núcleo, el bus USB, I2C y conceptos básicos de fotografía/video.

Quiero decir que todo esto fue posible gracias a la ayuda y consejo de Jean-François Moine y Hans de Geode (a cargo de varios subdrivers de GSPCA). Jean-François Moine es un desarrollador aficionado frances que realizó la reescritura del código original adaptandolo a la última versión del estándar Video4Linux. Hans de Geode es un hacker Holandes con cerca de 5 años de experiencia en el núcleo Linux, trabaja principalmente en el proyecto Fedora y actualmente esta a cargo de un proyecto para mejorar la experiencia de usuario en esa distribución de GNU/Linux con respecto a las Webcams.

Para terminar, quería comentar que al estar realizando los ajustes finales al controlador y estando ya soportada mi webcam en GSPCA, me enteré que este había sido enviado al núcleo para su inclusión en la versión 2.6.27. Es una satisfacción haber podido hacer andar mi webcam, pero me reconforta más colaborar con mi pequeño aporte para que algunas personas puedan utilizar su webcam en GNU/Linux sin mayores inconvenientes.

Referencias:

• Proyecto GSPCA v2 y página personal de Jean-François Moine: http://moinejf.free.fr/

• Proyecto SPCA5xx y GSPCA original: http://mxhaard.free.fr/spca5xx.html

• Proyecto Microdia: http://groups.google.com/group/microdia/

• Blog personal de Hans de Goede: http://hansdegoede.livejournal.com/