Durante años, los usuarios de Linux con tarjetas AMD Radeon han tenido una sensación bastante amarga: el hardware y el televisor estaban listos para disfrutar de HDMI 2.1, pero el sistema se quedaba atascado en las limitaciones de HDMI 2.0. Quien conectaba su PC con Linux a una tele 4K de última generación vía HDMI veía cómo, en la práctica, el ancho de banda disponible no daba para todo lo que prometía la ficha técnica de la gráfica.

Ese panorama empieza a moverse en serio. AMD ha enviado al kernel de Linux una primera serie de parches para el driver abierto AMDGPU que introduce soporte para HDMI FRL (Fixed Rate Link), el modo de transmisión que da vida al salto de ancho de banda de HDMI 2.1. No es todavía el paquete completo, pero sí el punto de inflexión que la comunidad llevaba años esperando, con impacto directo en equipos domésticos.

Del bloqueo del HDMI Forum a la apertura del estándar en Linux

El problema de fondo no era técnico, sino de licencias. El HDMI Forum llevaba años vetando una implementación totalmente abierta de HDMI 2.1 en controladores de código libre. Para que una función entre en el kernel de Linux, el código debe ser público, y ahí chocaban de frente las exigencias de confidencialidad del organismo que gestiona el estándar HDMI.

AMD había intentado durante mucho tiempo encontrar un encaje: publicar una implementación que hiciera funcionar HDMI 2.1 sin revelar los detalles que el HDMI Forum considera sensibles. En febrero de 2024, de hecho, el foro llegó a rechazar formalmente una propuesta de AMD para liberar un driver con soporte completo de HDMI 2.1 en Linux, lo que condenaba a las Radeon en este sistema a quedarse en el ancho de banda de HDMI 2.0.

Ese bloqueo imponía límites muy concretos: 4K a 120 Hz, 8K a 60 Hz, HDR completo o configuraciones de color sin recortes solo eran viables usando DisplayPort o directamente instalando Windows. En muchos hogares, donde conectar el PC del salón a la tele mediante HDMI es lo más normal, la consecuencia era clara: había que renunciar a parte de la calidad de imagen o al refresco alto aunque la tele y la gráfica fuesen totalmente compatibles con HDMI 2.1.

La situación empieza a cambiar con la llegada de los nuevos parches enviados por los ingenieros de AMD al driver AMDGPU. La gran novedad es la integración de HDMI FRL en el controlador del kernel, un paso que el HDMI Forum ya ha podido someter a pruebas de conformidad sin que, aparentemente, se vulneren sus requisitos de confidencialidad. Es el primer movimiento oficial que abre la puerta a HDMI 2.1 nativo en Linux sin depender de soluciones privadas.

Qué aporta HDMI FRL y por qué es la pieza clave de HDMI 2.1

El corazón de este avance es FRL, siglas de Fixed Rate Link, el nuevo modo de enlace que HDMI 2.1 introduce para sustituir al antiguo TMDS heredado de HDMI 2.0. Hasta ahora, las conexiones HDMI con GPUs AMD en Linux se veían obligadas a usar ese enlace antiguo, con un techo de ancho de banda insuficiente para las exigencias actuales del gaming y del vídeo de alta gama.

Con FRL, HDMI 2.1 es capaz de elevar el ancho de banda hasta los 48 Gbps si se utilizan cables certificados Ultra High Speed. Esa cifra es la que permite, en la práctica, enviar señal 4K a 120 Hz manteniendo HDR activo, reducir al mínimo el submuestreo de color y abrir la vía a resoluciones y tasas de refresco todavía más agresivas en monitores especializados.

Los parches presentados por AMD añaden precisamente este modo FRL al driver AMDGPU integrado en el kernel. Según la documentación remitida, la implementación ya ha superado un subconjunto representativo de las pruebas de conformidad del propio HDMI Forum, aunque aún está pendiente la validación completa que permita considerarlo totalmente certificado.

Conviene tener claro, eso sí, qué cubre esta primera fase y qué no. En este envío inicial no entran todavía funciones como Display Stream Compression (DSC) ni Variable Refresh Rate (VRR). DSC es esencial para combinar resoluciones muy altas con frecuencias de refresco ambiciosas sin saturar el enlace, y VRR resulta clave para sincronizar la tasa de refresco del panel con los fotogramas de la GPU, reduciendo tearing y tirones. Ambas capacidades siguen en fase de pruebas y se esperan en tandas posteriores de parches.

Con todo, el salto a FRL ya tiene impacto práctico. Lo que se desbloquea ahora es el transporte de datos de alta velocidad a través de HDMI 2.1, que era justo el cuello de botella que frenaba a quienes intentaban exprimir televisores 4K de 120 Hz o monitores de alta frecuencia en Linux. Aunque falten todavía algunas piezas del estándar, la base para aprovechar mejor esas pantallas ya está dentro del ecosistema de código abierto de AMD.

Valve, SteamOS y la presión para llevar HDMI 2.1 al salón

En paralelo al trabajo de AMD, varias fuentes apuntan a que Valve ha jugado un papel determinante en este giro. La compañía detrás de Steam, Steam Deck y SteamOS lleva tiempo empujando para que el ecosistema Linux pueda competir de tú a tú con Windows y las consolas cuando toca conectarse al televisor del salón.

Según diversos reportes, Valve habría estado presionando discretamente al HDMI Forum y a AMD para desbloquear esta situación. Para un dispositivo de salón, HDMI 2.1 es más relevante que DisplayPort, y no poder ofrecerlo en condiciones colocaba a SteamOS en desventaja frente a mini PCs con Windows o frente a consolas de última generación.

La compañía también se ha interesado por una implementación lo más abierta posible del estándar HDMI, ya que su ecosistema se apoya en hardware de AMD y en un sistema operativo basado en Linux. Al mismo tiempo, desarrolladores de la comunidad publicaron implementaciones experimentales que demostraban que era viable ofrecer soporte avanzado de HDMI 2.1 sin violar los principios del software libre.

Todo ese contexto ha desembocado en la serie de parches actual. Si AMD consigue cerrar el soporte completo —incluyendo DSC y VRR—, dispositivos como la Steam Machine o una futura Steam Deck 2 conectada al televisor podrían aprovechar HDMI 2.1 sin cambiar el hardware, solo mediante mejoras de software, drivers y validación. El límite pasaría a estar en el ritmo al que el kernel integre y estabilice estas funciones.

Limitaciones históricas de las Radeon en Linux vía HDMI

Hasta la llegada de estos cambios, la experiencia de muchos usuarios era clara: da igual lo potente que fuera la Radeon o lo avanzada que fuese la tele, si se usaba HDMI en Linux, tocar 4K a 120 Hz o plantearse 8K quedaba prácticamente descartado. El camino era conformarse con menos refresco o recurrir a DisplayPort siempre que el monitor lo permitiera.

Para quienes usan Linux como sistema principal, esto suponía una desventaja frente a Windows. Conectar una GPU AMD a una tele de gama alta en Windows y exprimir sus capacidades era mucho más sencillo; en Linux, en cambio, el usuario se chocaba con el muro de las licencias y la falta de soporte oficial de HDMI 2.1 en los controladores abiertos.

Con el soporte de FRL entrando en AMDGPU, esa brecha frente a Windows se reduce de forma visible. Ya no será obligatorio recurrir a DisplayPort para sacar todo el partido a la pantalla ni resignarse a una experiencia recortada al usar HDMI en Linux, siempre que el kernel y la distribución integren las versiones adecuadas del driver.

Impacto para los jugadores de Linux

En el día a día, los primeros en notar el cambio serán los usuarios que combinan tarjetas AMD Radeon, Linux y pantallas modernas conectadas por HDMI. Hasta ahora, para disfrutar de 4K con tasas de refresco altas y buena calidad de imagen era casi obligado tirar de Windows o de un monitor con DisplayPort plenamente soportado.

En entornos domésticos, donde es habitual que el ordenador de sobremesa o el mini PC se coloquen junto al televisor, aprovechar HDMI 2.1 es clave para el gaming en el salón. Con FRL funcionando en el driver abierto, esas configuraciones podrán aspirar a 4K a 120 Hz con HDR activo y menos sacrificios en color, siempre que tanto el televisor como el cable cumplan con el estándar Ultra High Speed.

Desde el punto de vista de la adopción de Linux para jugar, el movimiento es significativo. Se elimina una de las excusas más repetidas para seguir en Windows en equipos pensados para uso multimedia y gaming en el salón. Si la misma máquina ofrece una experiencia visual cercana en SteamOS o en distribuciones populares (Ubuntu, Fedora, Manjaro, Arch, etc.), la elección del sistema deja de estar condicionada por un cuello de botella en la salida de vídeo.

También los fabricantes de PCs y ensambladores salen beneficiados. Con este avance, podrán anunciar compatibilidad real con HDMI 2.1 bajo Linux en equipos basados en GPUs AMD, sin tener que matizar que para sacarle todo el partido es imprescindible usar Windows. Eso puede animar a ofrecer más configuraciones preinstaladas con distribuciones GNU/Linux orientadas a jugadores.

Estado actual del soporte y próximos pasos en el kernel

Pese al tono optimista, AMD insiste en que aún no estamos ante una pila HDMI 2.1 completa en el driver AMDGPU. Lo que ha llegado al kernel es un primer conjunto de parches que habilita el transporte de datos a alta velocidad mediante FRL y que ha pasado ya una parte relevante de las pruebas de conformidad del HDMI Forum.

Queda pendiente la integración de Display Stream Compression (DSC), imprescindible para combinar resoluciones extremas con tasas muy altas sin saturar el enlace, así como el soporte estable de Variable Refresh Rate (VRR), que ayuda a sincronizar la pantalla con los fotogramas de la GPU para suavizar la experiencia en juegos exigentes.

El proceso habitual en el desarrollo del kernel implica que estos parches atraviesen varias fases: revisión por parte de los mantenedores, pruebas comunitarias y, finalmente, integración en una versión estable del kernel. Ese recorrido puede durar desde unas semanas hasta varios meses, en función de los comentarios recibidos y de los posibles problemas que aparezcan en configuraciones concretas de hardware.

Para el usuario final, el cambio llegará vía actualización de sistema. Distribuciones como Ubuntu, Fedora o Arch Linux, así como SteamOS, irán incorporando progresivamente estos parches en sus kernels. En la mayoría de los casos, el usuario no tendrá que hacer nada más que mantener el sistema actualizado; no será necesario compilar drivers a mano salvo que se quiera ir por delante de las versiones oficiales.

Es previsible que las funciones más avanzadas de HDMI 2.1 aterricen antes en kernels recientes o ramas menos conservadoras que en las versiones LTS, que suelen priorizar la estabilidad. Aun así, el hecho de que el código actual ya esté pasando pruebas oficiales indica que la parte más compleja del trabajo técnico está encarrilada.

Con este movimiento, el soporte de HDMI 2.1 en Linux pasa de ser una promesa lejana a una realidad en fase de despliegue. La entrada de FRL en el driver abierto AMDGPU rompe por fin el techo de ancho de banda de HDMI 2.0 y abre una etapa en la que los usuarios de Radeon podrán aprovechar mejor sus televisores y monitores modernos, a la espera de que funciones como DSC y VRR terminen de completar el puzle.