Collabora propone una API de usuario para limitar el VRR en los drivers gráficos de Linux
Nicolas Frattaroli publica un RFC con 25 parches que define rangos y objetivos fijos de tasa de refresco para la VRR, más una propiedad de conector para QMS.
Collabora ha movido ficha en el debate sobre cómo se comporta la tasa de refresco variable (VRR) en Linux. Nicolas Frattaroli ha publicado una propuesta de API de espacio de usuario, acompañada de 25 parches, para que el software pueda fijar objetivos de tasa de refresco: un rango acotado en el que el VRR deba moverse, o un valor fijo. La serie añade además una propiedad de conector nueva para QMS (Quick Media Switching).
El motivo que da el autor no tiene nada de teórico. En sus palabras, la idea es "evitar la imperfección del mundo real": acotar el VRR a un rango limitado o anclarlo a un punto concreto da los beneficios de una presentación sin judder o de baja latencia dentro de las tasas de refresco esperadas, sin caer en las que provocan parpadeo visible de brillo. Ese parpadeo es el problema conocido de dejar que el panel baje demasiado en según qué condiciones.
La propiedad de conector para QMS va por otro camino: permite avisar por adelantado de un cambio de tasa en escenarios de reproducción multimedia, de forma que la TV no tenga que desactivar sus algoritmos de procesado para poder presentar a tasa completa sin aviso previo.
Qué se implementa y dónde está el código
Los parches implementan el VRR de tipo "Game Mode" en los helpers de estado de HDMI y también en el driver del Rockchip RK3588. No es un cambio de una sola pieza: toca la interfaz entre el kernel y el espacio de usuario, y por eso el diseño de esa uAPI es justo lo que se está discutiendo.
El tema se presentó también en el Display Next Hackfest de este año, así que hay contexto público más allá de la lista de correo. Los parches en formato RFC están en dri-devel, y quien quiera probarlo en el lado del compositor tiene una rama vrr-limiter contra Weston, la implementación de referencia de Wayland.
Conviene recordar que esto es una petición de comentarios, no código camino de mainline. La pregunta de fondo es quién debe mandar aquí: si el kernel expone el control y deja que juegos, aplicaciones y compositores decidan el rango, o si esa lógica se queda en el compositor y el driver se limita a obedecer. Mientras se resuelve, lo que hay es una interfaz propuesta que aún puede cambiar de forma antes de que nadie la empaquete en una distribución.
