Con la ventana de combinación de Linux 6.2 detrás de nosotros, el trabajo de características para los cambios del Direct Rendering Manager (DRM) dirigidos ahora al kernel de Linux 6.3 ha comenzado a hacer cola con DRM-Next.
Hoy se envió un lote inicial de material drm-misc-next de las vacaciones. No hay demasiados cambios en el controlador DRM principal y pequeño en este impulso, considerando que muchos desarrolladores se tomaron un tiempo libre durante Navidad y Año Nuevo.
Sin embargo, se destaca el código DRM que ve algunas mejoras de soporte de TV analógica para 2023. El desarrollador de código abierto desde hace mucho tiempo Maxime Ripard ha trabajado para agregar una propiedad de modo”TV analógica”a la API de espacio de usuario del conector DRM y realizar otras mejoras básicas de DRM en torno al soporte de TV analógica.
De este gran parche serie que ha estado en desarrollo durante varios meses, explica Maxime Ripard:
Aquí hay una serie que tiene como objetivo mejorar la compatibilidad con los modos con nombre de la línea de comandos y, lo que es más importante, cómo tratamos con todas las variantes de TV analógica.
La compatibilidad con los modos con nombre se introdujo inicialmente para permitir especificar el modo de TV analógica que se utilizará.
Sin embargo, esto estaba causando varios problemas:
* El nombre del modo analizado en la línea de comando se pasaba directamente al controlador, que tenía que averiguar con qué modo se suponía que debía coincidir ;
* Descubrir eso no fue realmente fácil, ya que el argumento video=o qué espacio de usuario podría ni siquiera tener un nombre en primer lugar, sino que podría haber pasado un modo con los mismos tiempos;
* La alternativa para hacer coincidir los tiempos funcionaba principalmente siempre que admitiéramos una de 525 líneas (probablemente NSTC) y una de 625 líneas (PAL), pero no podíamos diferenciar entre dos modos con el mismos tiempos (NTSC vs PAL-M vs NSTC-J por ejemplo);
* También hubo cierta superposición con la propiedad del modo tv registrada por drm_mode_create_tv_properties(), pero los modos nombrados no interactuaban con esa propiedad en absoluto.
* Aunque esa propiedad era genérica, sus posibles valores eran específicos para cada controlador, lo que dificultaba algunos soportes genéricos.
Por lo tanto, elegí abordarlo en varios pasos:
* Se introdujo una nueva propiedad de norma de TV, con valores genéricos, cada controlador informa a través de una máscara de bits qué estándar admite en el espacio de usuario. ;
* Esta opción se agregó al código de análisis de la línea de comando para poder especificarlo en la línea de comando del kernel, y se crearon nuevos ayudantes atomic_check y reset para integrarse correctamente en atomic KMS;
* El código de análisis del modo con nombre ahora está creando un modo de visualización adecuado para el modo con nombre dado y, por lo tanto, el estándar de TV será parte del estado del conector;
* Dos controladores fueron convertidos y probados por ahora (vc4 y sun4i), con algún código de compatibilidad con versiones anteriores para traducir el antiguo modo de TV al nuevo modo de TV;
Como se señaló inicialmente, el controlador VC4 DRM utilizado principalmente por las computadoras de placa única Raspberry Pi y luego el controlador Sun4i DRM para los diversos SoC Allwinner que usan ese controlador de pantalla se benefician inicialmente de estas mejoras de soporte de TV analógica.
El trabajo de la televisión analógica es el cambio más interesante entre los drm-misc-next pull de hoy . Espere más cambios interesantes en el controlador DRM en cola en las próximas semanas antes de la ventana de combinación de Linux 6.3 a finales de febrero.
