El soporte de HDR en Linux lleva años avanzando más despacio de lo que muchos usuarios de escritorio, creadores de contenido y jugadores habrían querido. El problema no ha estado tanto en el hardware como en la complejidad de coordinar kernel, drivers, compositor y gestión avanzada de color dentro de un ecosistema mucho más fragmentado que el de Windows o macOS. En ese contexto, AMD ha dado ahora un paso técnico relevante para mejorar el tratamiento del color en Linux, especialmente en el entorno de KDE, y lo ha hecho con un detalle que ha llamado especialmente la atención: parte del trabajo se desarrolló con ayuda de Claude, el modelo de Anthropic.
El responsable de este avance es Harry Wentland, ingeniero de AMD muy implicado en la evolución del subsistema gráfico de Linux. En una publicación técnica recogida por Planet Freedesktop, Wentland explica que ha trabajado en nuevos parches para DRM y AMDGPU, así como en integración del lado del compositor KWin, con el objetivo de cubrir una carencia importante de la actual API de color del kernel: la conversión de espacio de color o CSC. La noticia, por tanto, no debería interpretarse como “el HDR ya está completamente resuelto en Linux”, sino como un avance serio y tangible que todavía necesita revisión, pruebas adicionales y proceso de integración aguas arriba.
Un paso técnico importante para el color avanzado en Linux
Para entender por qué este desarrollo importa, conviene mirar primero la base. La documentación oficial del kernel explica que la Color Pipeline API nace para permitir transformaciones complejas de color con poca o ninguna carga adicional para CPU o shaders, y lo hace mediante una API “prescriptiva” basada en operaciones bien definidas, como LUT 1D, LUT 3D o matrices. Esa aproximación es especialmente importante en HDR, donde no basta con decir cuál es el espacio de color de entrada y el de salida: también hay que definir con precisión cómo se realiza esa transformación para que el resultado visual sea coherente.
La propia documentación del kernel también deja claro por qué Linux lo tiene más difícil que otros sistemas operativos. Mientras en otras plataformas suele haber una relación más cerrada entre compositor y driver, en Linux existe una relación de “muchos a muchos”: varios compositores, varios drivers y distintas formas de entender la gestión del color. Eso complica mucho lograr una experiencia uniforme, pero también explica por qué cada avance en esta capa del stack gráfico resulta tan relevante.
En este caso, Wentland se ha centrado en añadir soporte de conversión de espacio de color mediante un nuevo drm_colorop de tipo CSC. El problema era concreto: KWin podía recibir vídeo en formatos como NV12 o P010 a través de Wayland, pero no podía descargar correctamente toda esa conversión al hardware de pantalla porque la API de color todavía no contemplaba esa pieza. El resultado era que el compositor terminaba resolviendo color, escalado, tone mapping y composición por OpenGL en lugar de aprovechar mejor el pipeline de color del hardware. Con la nueva pieza de CSC, esa limitación empieza a desbloquearse.
El blog técnico de Wentland va incluso más allá y muestra ejemplos prácticos. Tras introducir el nuevo bloque de CSC y conectarlo con KWin, el sistema ya puede manejar mejor la composición acelerada de ciertos buffers de vídeo. Después entra en otro punto clave: el uso de una 3D LUT para empaquetar el pipeline interno de color de KWin y trasladarlo al hardware de AMD. Según explica, eso permite representar pipelines complejos con una sola operación 3D LUT y abrir la puerta a una composición por hardware más avanzada también con contenido HDR.
Claude no sustituye al ingeniero, pero sí ha escrito parte del trabajo
La parte más llamativa del caso es la intervención de Claude. Wentland reconoce de forma explícita que utilizó Claude Sonnet de forma intensiva durante este trabajo y llega a afirmar que el modelo “básicamente escribió todo el código”. Aun así, el propio ingeniero introduce un matiz que resulta crucial en un proyecto como Linux: un modelo de lenguaje puede acelerar la comprensión de bases de código complejas y ayudar a producir código que encaje en ellas, pero la responsabilidad final sigue siendo humana.
Esa advertencia no es menor. Wentland insiste en que los desarrolladores no deben dejar de “poseer” su código por el hecho de haber usado un LLM. En la práctica, eso significa revisar lo generado, dirigir activamente la herramienta y no enviar parches de baja calidad a los mantenedores. En un ecosistema como el del kernel de Linux o KDE, donde la revisión técnica y el consenso siguen siendo fundamentales, esa postura marca una diferencia clara entre usar la Inteligencia Artificial como apoyo y usarla como excusa para saturar proyectos open source con contribuciones mal verificadas.
Además del propio código del driver y del compositor, Wentland también ha enseñado herramientas auxiliares para depuración. Entre ellas, una pestaña nueva en KWin para activar y desactivar dinámicamente la composición por hardware y otra vista relacionada con UMR para visualizar la programación de la parte de display en AMD. No todo ese trabajo está listo para integrarse sin más, pero sí deja claro que el uso de Claude no se limitó a una anécdota o a un par de funciones sueltas: formó parte de un proceso más amplio de exploración, prototipado y ajuste sobre código real.
El HDR en Linux mejora, pero todavía no está cerrado
Lo más interesante de fondo es que este trabajo toca uno de los frentes más delicados del escritorio Linux moderno: la calidad de imagen en monitores HDR y OLED sin disparar carga de GPU ni empeorar la experiencia del usuario. La documentación oficial del kernel ya planteaba precisamente ese objetivo: usar los bloques fijos del hardware cuando sea posible y recurrir a shaders o CPU solo cuando no quede otra opción. En otras palabras, no se trata solo de que el HDR “funcione”, sino de que funcione bien, con coherencia visual y con una ruta eficiente de procesamiento.
Ahora bien, el propio Wentland rebaja cualquier triunfalismo. En su publicación deja claro que el código todavía necesita más pruebas, que la parte de KWin requerirá comentarios de sus mantenedores y que aún observa comportamientos por pulir, como fallos ocasionales en la aplicación de la 3D LUT o superficies que no aparecen como candidatas a offload donde cabría esperarlo. También cita dudas con algunos juegos y con la reproducción de YouTube en Firefox, mientras que otros vídeos locales sí funcionan correctamente. Ese es, probablemente, el dato más valioso de toda la historia: el avance es real, pero el trabajo no está terminado.
En paralelo, Phoronix recuerda que este esfuerzo llega después de la incorporación de la DRM Color Pipeline API a Linux 6.19, una base que llevaba más de dos años de desarrollo y debate. Eso ayuda a situar esta novedad en su contexto correcto: no es una mejora aislada, sino una pieza más dentro de una modernización mucho más amplia del color en Linux. Y también es una señal interesante de cómo empiezan a cambiar los procesos de desarrollo en software de bajo nivel. No porque una IA vaya a reemplazar a los ingenieros del kernel, sino porque ya está empezando a participar en tareas que hasta hace poco parecían reservadas exclusivamente a especialistas humanos muy concretos.
Preguntas frecuentes
¿Qué mejora exacta ha introducido AMD para el HDR en Linux?
AMD ha trabajado en soporte de conversión de espacio de color (CSC) dentro del pipeline de color de DRM, además de parches para AMDGPU y ejemplos de integración con KWin. Esa pieza es importante porque la API actual todavía no cubría bien esa parte y obligaba a resolver más trabajo desde el compositor.
¿Claude ha desarrollado por sí sola el driver de AMD para Linux?
No. Harry Wentland reconoce que utilizó Claude Sonnet de forma intensiva y que el modelo escribió gran parte del código, pero también insiste en que el desarrollador sigue siendo responsable de revisar, dirigir y validar todo lo generado antes de enviarlo a mantenedores y comunidades.
¿Este avance significa que el HDR en Linux ya está totalmente resuelto?
Todavía no. Wentland explica que el trabajo necesita más pruebas, que la parte de KWin probablemente requerirá más cambios tras la revisión de sus mantenedores y que aún hay comportamientos por depurar, incluidos algunos casos con vídeo en Firefox y dudas sobre juegos.
¿Por qué es tan importante la conversión de espacio de color en Linux?
Porque el HDR y la gestión moderna del color no dependen solo del brillo, sino de transformar correctamente el contenido entre distintos espacios de color, curvas y formatos. La documentación oficial del kernel subraya que Linux necesita una forma precisa y consistente de describir y programar esas operaciones para aprovechar mejor el hardware sin aumentar la carga de CPU o shaders.
