Por qué tu monitor de 240 o 360 Hz se queda en 120 Hz por HDMI en Linux (y cómo arreglarlo)

TMDS y FRL: el cuello de botella

HDMI puede transmitir la imagen de dos formas distintas y la elección entre una u otra determina la frecuencia máxima.

• TMDS es el sistema clásico, el de HDMI 2.0 y anteriores. Su techo es una frecuencia de 600 MHzref. Con color normal de 8 bits, eso equivale a unos 14,4 Gbps de imagen.
• FRL (Fixed Rate Link, enlace de velocidad fija) llegó con HDMI 2.1. Usa cuatro canales de hasta 12 Gbps cada uno, 48 Gbps en total. Descontado lo que ocupa la codificación (16b/18b), quedan unos 42,6 Gbps de imagenref. Da para 4K a 144 Hz o 1440p a 360 Hz sin comprimir.

No basta con que un monitor o un televisor digan «HDMI 2.1». Para superar unos 14 Gbps, el ordenador, el cable y la pantalla deben hablar FRL. Si el controlador de la gráfica no sabe hacerlo, todo vuelve a TMDS y la pantalla funciona como si fuera HDMI 2.0.

Cómo se calcula lo que necesita un modo

Cada modo de pantalla tiene un reloj de píxel, que es la cantidad de píxeles que la gráfica envía por segundo, incluyendo también unos márgenes invisibles alrededor de la imagen. Al multiplicar este valor por 24 bits (8 por cada color: rojo, verde y azul), se obtiene el volumen de datos que viajan por el cable.

El monitor de 360 Hz del ejemplo anuncia estos modos en sus datos internos (el EDID):

• 2560×1440 a 120 Hz: 555,72 MHz. Cabe en TMDS.
• 2560×1440 a 240 Hz: 1111,25 MHz, unos 26,7 Gbps. No cabe.
• 2560×1440 a 360 Hz: 1667,17 MHz, unos 40 Gbps. No cabe.

Por ello, sin FRL, Linux solo ofrece hasta 120 Hz en 1440p. Algunos monitores alcanzan los 144 Hz, justo en el límite, gracias a márgenes más ajustados.

DSC: comprimir cuando ni FRL basta

DSC (Display Stream Compression) es una técnica de compresión de imagen diseñada para ser imperceptible. Reduce considerablemente el ancho de banda y permite utilizar modos que no cabrían sin comprimir. DisplayPort la incorpora desde la versión 1.4ref y HDMI 2.1 también la admite sobre FRL.

En el ejemplo, el monitor admite FRL hasta 40 Gbps (cuatro canales a 10 Gbps). Una vez descontada la codificación, quedan unos 35,6 Gbps. Los 40 Gbps que requieren 1440p a 360 Hz no caben ni con FRL: incluso en Windows, ese modo viaja comprimido con DSC.

Qué cabe en cada conexión

La tabla utiliza márgenes reducidos estándar (CVT-RB v2) y color de 8 bits por canal, sin HDR. Estos son los mínimos habituales: muchos monitores emplean márgenes algo mayores y requieren un poco más.

El término «Justo» significa que el resultado depende de los márgenes exactos del monitor. Por ejemplo, con los márgenes estándar, 1080p a 240 Hz requiere 583 MHz y cabe en TMDS. El monitor del ejemplo utiliza 625 MHz para ese modo, por lo que sin FRL tampoco aparece. Con 10 bits por color (HDR), todos los valores suben un 25 %.

Una licencia, no un fallo del hardware

La gráfica que en Windows saca 360 Hz por HDMI es la misma que en Linux se queda en 120 Hz. Lo que cambia es el controlador.

El controlador de AMD para Windows es cerrado y cumple las condiciones de la licencia de HDMI. En cambio, el de Linux, amdgpu, es de código abierto y está integrado en el núcleo. Aquí reside el conflicto: la especificación de HDMI 2.1 no es pública y el HDMI Forum, el organismo que la controla, no permitía publicar el código que la implementaref.

De la negativa de 2024 a Linux 7.4

• Febrero de 2024. El HDMI Forum rechazó la propuesta de AMD de añadir HDMI 2.1 a su controlador libre. AMD avisó de que en Linux solo ofrecería HDMI 2.0 y recomendó DisplayPort a quien necesitara másref.
• Mayo de 2026. AMD publicó por fin los parches de FRL para amdgpu. La primera versión no incluía DSCref; una revisión posterior la añadióref. AMD no ha explicado qué cambió con el HDMI Forum. La prensa especializada lo relaciona con el empuje de Valveref.
• Linux 7.2, verano de 2026. El código entra en el núcleo, pero desactivado de serie. El motivo: aún faltaba la frecuencia variable (VRR, FreeSync) por HDMI 2.1, y quien ya la usaba habría notado un retrocesoref. Las novedades de esa versión están en Linux 7.2: sus principales novedades.
• Linux 7.3, octubre de 2026. Sigue igual: FRL existe, pero apagado.
• Linux 7.4. FRL pasa a estar activado de serie, junto con VRR, FreeSync y ALLM (el modo de baja latencia) por HDMI 2.1. Los cambios entraron en la ventana de desarrollo de finales de octubre de 2026ref.

El código del núcleo lo confirma. En Linux 7.3, el interruptor DC_FRL_MASK (valor 0x400) está documentado como «desactivado de serie»ref. En la rama de desarrollo que dará lugar a 7.4, el mismo interruptor ya figura como «activado de serie»ref.

Cómo saber qué te está limitando

Estas cinco comprobaciones permiten saber qué ocurre en cada equipo. Ninguna de ellas realiza cambios.

1. El nombre de la salida HDMI

Linux expone cada conector de vídeo como una carpeta en /sys/class/drm:

ls /sys/class/drm/

card1  card1-DP-1  card1-DP-2  card1-eDP-1  card1-HDMI-A-1  ...

eDP-1 corresponde a la pantalla del portátil y HDMI-A-1 al puerto HDMI. El número de card varía según el equipo. Para saber en cuál está enchufado el monitor:

cat /sys/class/drm/card*-HDMI-A-*/status

2. Lo que dice el monitor que admite

En esa carpeta se encuentra el archivo edid, donde se guarda la ficha técnica que envía el monitor. El programa edid-decode se encarga de traducirla; el paquete suele llamarse igual en todas las distribuciones:

edid-decode /sys/class/drm/card1-HDMI-A-1/edid

La salida es extensa. Estas líneas son las más importantes (ejemplo de un monitor de 360 Hz):

Maximum TMDS Character Rate: 600 MHz
Max Fixed Rate Link: 3 and 6 Gbps per lane on 3 lanes, 6, 8 and 10 Gbps on 4 lanes
Supports VESA DSC 1.2a compression
VTDB 2:  2560x1440  359.999050 Hz  16:9  578.878 kHz  1667.170000 MHz
VTDB 3:  2560x1440  239.956900 Hz  16:9  385.851 kHz  1111.250000 MHz

• Maximum TMDS Character Rate es el techo sin FRL: 600 MHz.
• Max Fixed Rate Link indica que el monitor sí admite FRL, aquí hasta 10 Gbps por canal en cuatro canales (40 Gbps).
• Supports VESA DSC dice que acepta imagen comprimida.
• Las líneas VTDB (bloques DisplayID de tipo VII) son los modos de alta frecuencia, con su reloj de píxel al final.

Si el monitor no muestra la línea de FRL, no admite HDMI 2.1 completo y, por HDMI, no superará lo que permite TMDS.

3. Si el portátil usa un chip convertidor

journalctl -k | grep -i -E "frl|pcon"

Si aparece esta línea, la salida HDMI pasa por un convertidor de DisplayPort a HDMI, un PCONref:

amdgpu 0000:65:00.0: [drm] DP-HDMI FRL PCON supported

Ese caso tiene su propio apartado más abajo.

4. Si FRL está activado en AMD

cat /sys/module/amdgpu/parameters/dcfeaturemask

El número se muestra en decimal. Con los valores de fábrica de Linux 7.2 y 7.3 el resultado es 2ref, lo que significa que FRL está apagado. Si el valor es 1026 (0x402 en hexadecimal), FRL está activado. En general, FRL está activo si el número, al pasarlo a hexadecimal, incluye el bit 0x400.

5. Los modos que ofrece el escritorio

• KDE Plasma: kscreen-doctor -o muestra todas las salidas con sus modos.
• Escritorios basados en wlroots (Sway, Hyprland…): wlr-randr, o hyprctl monitors en Hyprland.
• Sesiones X11: xrandr.
• GNOME: Configuración › Pantallas, en la lista de frecuencias.

Si el modo de 240 o 360 Hz no aparece en la lista, es que el controlador lo ha descartado por falta de ancho de banda.

Activar FRL en Linux 7.2 y 7.3

En Linux 7.2 y 7.3, FRL se activa mediante un parámetro del núcleo: amdgpu.dcfeaturemask. Se trata de un número donde cada bit habilita una función de pantalla del controlador y, en el caso de FRL, el bit correspondiente es el 0x400ref.

Paso 1: calcular el valor

No basta con escribir 0x400. Ese número sustituye al valor completo y desactivaría los demás bits que vienen activados de serie, como el 0x2. Lo correcto es sumar el bit de FRL al valor actual. En una terminal bash:

printf '0x%x\n' $(( $(cat /sys/module/amdgpu/parameters/dcfeaturemask) | 0x400 ))

0x402

El resultado con los valores de fábrica es 0x402. Si obtienes otro número, usa el que salga.

El nombre del parámetro es dcfeaturemask, escrito todo junto y sin guiones bajosref. Si se usa cualquier otra grafía, el núcleo lo ignora sin avisar en pantalla.

Paso 2: añadirlo al arranque

Esto depende del gestor de arranque de cada distribución. En cualquier caso, hay que añadir amdgpu.dcfeaturemask=0x402 (o el valor calculado) a la línea de opciones del núcleo, separándolo con un espacio de lo que ya esté escrito.

GRUB (Ubuntu, Linux Mint, Debian, Pop!_OS, Arch con GRUB). Edita el archivo /etc/default/grub con permisos de administrador y añade el parámetro dentro de las comillas:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.dcfeaturemask=0x402"

Después, regenera la configuración. En Ubuntu, Mint y Debian:

sudo update-grub

En Arch y derivadas con GRUB:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Fedora. Un solo comando lo añade a todos los núcleos instalados:

sudo grubby --update-kernel=ALL --args="amdgpu.dcfeaturemask=0x402"

Bazzite, Fedora Silverblue y otras distribuciones inmutables con rpm-ostree:

rpm-ostree kargs --append=amdgpu.dcfeaturemask=0x402

systemd-boot (Pop!_OS reciente, EndeavourOS y otras). El parámetro debe añadirse en la línea options de los archivos situados en /boot/loader/entries/ (o en /efi/loader/entries/ en algunos equipos). Si la distribución genera dichas entradas a partir de /etc/kernel/cmdline, hay que añadirlo en ese archivo y volver a generarlas con la herramienta de la distribución; de lo contrario, el cambio se perderá en la siguiente actualización del núcleo.

Limine (CachyOS). Edita /etc/default/limine y añade el parámetro al final de la línea KERNEL_CMDLINE[default]+=, dentro de las comillas. Después:

sudo limine-update

Paso 3: reiniciar y comprobar

Tras reiniciar, estas dos órdenes confirman el cambio:

cat /proc/cmdline
cat /sys/module/amdgpu/parameters/dcfeaturemask

La primera debe incluir amdgpu.dcfeaturemask=0x402 y la segunda debe devolver 1026, que es el valor de 0x402 en decimal. A partir de ahí, los modos de 240 o 360 Hz deberían aparecer en la configuración de pantalla, siempre que la conexión lo permita.

Cómo deshacerlo

Basta con quitar el parámetro del mismo archivo y repetir el comando del gestor de arranque. En Fedora, usa --remove-args en lugar de --args; en rpm-ostree, --delete en lugar de --append.

Si el monitor se queda en negro y no hay otra pantalla, el parámetro se puede quitar solo para un arranque. En GRUB, systemd-boot y Limine, se elige la entrada del menú, se pulsa e, se borra el texto amdgpu.dcfeaturemask=0x402 y se arranca. Ese cambio no se guarda.

Con Linux 7.4, nada que hacer

Cuando la distribución se actualice a Linux 7.4, FRL vendrá activado y el parámetro ya no será necesario. En ese momento, conviene quitarlo para regresar a los valores de fábrica. Si FRL diera problemas en 7.4, el mismo parámetro sirve para desactivarlo: el valor actual sin el bit 0x400ref. En la rama de desarrollo de 7.4, el valor de fábrica pasa a ser 0x402, por lo que para apagar FRL quedaría amdgpu.dcfeaturemask=0x2ref.

Portátiles: el chip convertidor (PCON)

Muchos portátiles no cuentan con HDMI 2.1 nativo. En estos casos, la gráfica emite una señal DisplayPort que un chip situado junto al puerto convierte a HDMI 2.1; este chip se denomina PCON (protocol converter). Algunas tarjetas gráficas también lo utilizan: las Intel Arc A750 y A770 Limited Edition integran un Realtek RTD2173 para ofrecer HDMI 2.1ref.

Cuando hay un PCON, la imagen se transmite en dos tramos y el más estrecho es el que manda:

Si el registro del núcleo muestra el mensaje DP-HDMI FRL PCON supported, se trata de este caso. El tramo de DisplayPort suele ser DisplayPort 1.4 a su velocidad máxima (HBR3, cuatro canales), con 25,92 Gbps útilesref. Da igual que el monitor admita 40 Gbps por HDMI: sin comprimir, por ese primer tramo no pasa más.

Lo que pasó en el ejemplo

En el portátil con Radeon integrada y monitor de 360 Hz, el registro mostraba el PCON. Al activar FRL con amdgpu.dcfeaturemask=0x402:

• Apareció 1920×1080 a 240 Hz. El monitor lo define con 625 MHz, un poco más de lo que permite TMDS. Con FRL, cabe.
• No aparecieron 2560×1440 a 240 Hz ni a 360 Hz. Piden unos 26,7 y 40 Gbps con los márgenes del monitor. Los dos superan los 25,9 Gbps del tramo de DisplayPort.
• Tampoco apareció 1920×1080 a 360 Hz, aunque sobre el papel (22,5 Gbps) cabría. No todo lo que cabe en las cuentas acaba en la lista del controlador.

En Windows, los 240 y 360 Hz funcionan en ese mismo portátil porque el controlador comprime la imagen con DSC en ese primer tramo. Sin comprimir, no cabrían. El código de Linux (7.2 y 7.3) también contempla DSC a través de un PCON, pero solo lo usa si el chip declara que lo admiteref. En el ejemplo, con Linux 7.3, no se activó. No hay fecha anunciada para que este caso mejore.

Modos a medida: subir lo que se pueda

Existe margen entre los 120 y los 240 Hz. Un modo a medida con márgenes reducidos puede caber en el tramo de DisplayPort. En el ejemplo, funcionaron 2560×1440 a 200 Hz y a 220 Hz (unos 23 Gbps). Es necesario tener activado FRL: sin él, no pasa nada que supere los 600 MHz.

KDE Plasma 6.6 o posterior permite crear modos desde la terminalref. La frecuencia se indica en milésimas de hercio (220 Hz = 220000) y el parámetro reduced solicita márgenes reducidosref:

kscreen-doctor output.HDMI-A-1.addCustomMode.2560.1440.220000.reduced

El modo aparece en Configuración del sistema › Pantalla. Al elegirlo, Plasma pregunta si quieres conservarlo. Si el monitor se queda en negro, basta con esperar 15 segundos y volverá solo a la configuración anterior. Para borrar un modo, kscreen-doctor -o muestra la lista de modos personalizados con su número, y este comando borra el primero:

kscreen-doctor output.HDMI-A-1.removeCustomMode.0

En sesiones X11, el modo se calcula con cvt -r 2560 1440 220 y se añade mediante xrandr --newmode y xrandr --addmode. En GNOME sobre Wayland no existe una forma sencilla de crear modos.

Lo recomendable es subir la frecuencia poco a poco: 200, 210, 220 Hz… y quedarse con el último valor que se vea bien.

La solución fiable: DisplayPort

DisplayPort no presenta los problemas de licencias de HDMI. El controlador libre de AMD lo gestiona desde hace años, incluyendo la compresión DSC. Esta fue la recomendación de la propia AMD cuando el HDMI Forum rechazó su propuestaref. Gracias a DisplayPort 1.4 y DSC, las resoluciones 1440p a 360 Hz o 4K a 240 Hz funcionan en Linux sin necesidad de realizar ajustes.

Casi todos los monitores de 240 Hz o más tienen al menos una entrada DisplayPort. Las opciones según el equipo:

• Ordenador de sobremesa: un cable DisplayPort directo de la gráfica al monitor. Conviene que sea un cable DisplayPort 1.4 certificado por VESA; suelen venderse como «8K» o «HBR3».
• Portátil con USB-C que saca vídeo: un cable de USB-C a DisplayPort. El puerto debe admitir DisplayPort Alt Mode; suele indicarse con el logotipo de DisplayPort junto al puerto o en las especificaciones. Los puertos USB4 y Thunderbolt lo incluyen.
• Portátil sin USB-C con vídeo: solo queda HDMI, con FRL activado y, si hay PCON, los modos a medida del apartado anterior.

Puedes encontrar más detalles sobre cables, versiones y velocidades en DisplayPort 2.1: qué es y cuándo lo necesitas y en la comparativa HDMI frente a DisplayPort para jugar.

¿Y con NVIDIA o Intel?

El bloqueo afecta a los controladores libres integrados en el núcleo y cada fabricante se encuentra en un punto distinto.

NVIDIA

• Controlador propio de NVIDIA. Admite HDMI 2.1 con FRL y DSC. El código de pantalla, que comparten la versión clásica y la de módulos abiertos, lo implementaref. Con este controlador, una RTX conectada por HDMI 2.1 no tiene el problema de este artículo.
• Nouveau, el controlador libre del núcleo (y NVK, el controlador Vulkan de Mesa que funciona sobre él). En abril de 2026, David Airlie (Red Hat) consiguió FRL en una gráfica Ampere, apoyándose en el firmware GSP de NVIDIAref. Para Linux 7.4 se prepara el terreno para DSC, pero no hay fecha para que esté completoref. Quien use Nouveau o NVK y necesite alta frecuencia hoy debe usar DisplayPort.

Intel

• HDMI 2.1 mediante PCON. El controlador i915 sabe configurar un convertidor externo (entrenar el enlace FRL y usar su DSC) desde Linux 5.12, de 2021ref. Algunas tarjetas Arc A y muchos portátiles Intel ofrecen HDMI 2.1 así, con el mismo tope del tramo de DisplayPort que en AMD.
• HDMI 2.1 nativo. Para Meteor Lake y posteriores, Intel publicó en agosto de 2026 una serie de 44 parches con FRL. En Panther Lake ya consigue 4K a 120 Hz. Todavía no está en el núcleo, no incluye DSC y la propia Intel la describe como trabajo en cursoref.

En los tres casos, la conclusión es la misma: si el monitor dispone de DisplayPort y el equipo puede utilizarlo, es la opción que menos sorpresas da en Linux.