AMD lands first HDMI 2.1 FRL code in Linux 7.2 DRM pull

Linux graphics maintainers merged the Direct Rendering Manager driver updates for Linux 7.2, with AMDGPU HDMI 2.1 Fixed Rate Link support as the headline change for Radeon users.

AMD keeps the feature off by default in this cycle, and Linux 7.2 does not deliver a complete HDMI 2.1 implementation for AMDGPU. The merge still matters for anyone who runs a modern TV or monitor from a Radeon card over HDMI, because FRL gives AMD's open-source driver the transport layer it needs for higher resolution and refresh-rate modes.

HDMI 2.0 uses TMDS signaling and tops out at 18 Gbps raw bandwidth. HDMI 2.1 FRL raises the ceiling through fixed-rate lane modes that can reach 48 Gbps raw bandwidth on capable GPUs, cables and displays. That headroom can carry modes such as 4K at 120 Hz, 5K-class desktop output or 8K with compression, depending on the display pipeline and format.

For Linux users, the missing piece has hurt most on living-room PCs and workstation desks with HDMI-only displays. DisplayPort users have had more headroom for years. HDMI 2.1 support on Linux has moved slower because GPU vendors, the HDMI Forum's terms and open driver work all shaped the path upstream.

The Linux 7.2 DRM pull also adds AMDGPU DC Power Module support. AMD designed that code to match more of Radeon Software's display power behavior on Windows. If the code works as intended, Linux users should see fewer display power bugs, cleaner suspend and resume behavior and better idle behavior on Radeon systems.

Product impact

Radeon owners should treat Linux 7.2 as a foundation release for HDMI 2.1, not a finished switch to flip across every system.

AMDGPU now has initial FRL plumbing in the kernel. AMD still needs more code before users can expect broad HDMI 2.1 behavior across common displays. Kernel developers merged the first layer, then AMD can connect validation, mode handling and policy around it in later cycles.

That distinction matters for builders. A Radeon RX 7000 card, an HDMI 2.1 TV and a certified Ultra High Speed HDMI cable do not guarantee 4K 120 Hz from Linux 7.2 on day one. The kernel contains early support, but AMD leaves it disabled while engineers finish the implementation.

The release also carries AMDGPU fixes for systems that use non-4K kernel page sizes, including ARM and POWER machines. That work helps Radeon cards behave better outside the usual x86 desktop path, which matters for workstation boards, embedded Linux systems and homelab hosts with mixed CPU architectures.

{{IMAGE:2}}

Performance data

AMD did not publish new Radeon gaming or display benchmarks with this merge. The useful numbers come from the display link itself.

Link mode	Raw bandwidth	Practical effect
HDMI 2.0 TMDS	18 Gbps	Common 4K 60 Hz ceiling without compression
HDMI 2.1 FRL 6 Gbps x 4	24 Gbps	More room for high refresh 4K modes with format trade-offs
HDMI 2.1 FRL 8 Gbps x 4	32 Gbps	Stronger 4K 120 Hz fit on capable displays
HDMI 2.1 FRL 10 Gbps x 4	40 Gbps	More margin for high bit depth and chroma options
HDMI 2.1 FRL 12 Gbps x 4	48 Gbps	Top HDMI 2.1 transport rate

A Linux desktop builder should measure the feature in three places once AMD enables it: link rate, mode list and frame pacing. The kernel can expose a display mode, while the compositor still needs to present frames on time. Games and media apps add another layer through Vulkan, OpenGL, VA-API or Wayland behavior.

Power consumption deserves the same discipline. HDMI FRL can draw more link power than lower-rate TMDS modes. AMD's new DC Power Module could offset some of that cost through better display idle states, but users need wall-power and sensor data before they call it a win.

A useful test matrix would compare idle desktop power at 4K 60 Hz, 4K 120 Hz and VRR on the same display. Builders should log GPU package power, display engine clocks, memory clocks and system wall draw. Radeon cards often raise memory clocks for high-refresh multi-monitor setups, so the display mode can change idle power by more than the link alone suggests.

Compatibility notes

Radeon users need a GPU with HDMI 2.1-capable hardware, a display that supports FRL and an Ultra High Speed HDMI cable. Any weak link drops the stack back to a lower mode or prevents the target refresh rate from appearing.

Linux 7.2 also brings AMD work for next-generation graphics IP, though AMD's block-by-block enablement makes the exact product mapping hard to name from the merge text. That pattern fits recent AMD upstream work: engineers land display, graphics, media and power blocks across multiple cycles before the company names the retail silicon.

AMDXDNA also gains expandable heap support and early enablement for next-generation AIE4 NPU hardware. The same DRM pull adds new power-management features for AMD's AMDXDNA driver and Intel's IVPU NPU driver, which matters for Ryzen AI and Core Ultra systems that expose NPUs to Linux workloads.

Intel's graphics updates cover background color property support in DRM, more Crescent Island enterprise AI accelerator work, Panel Replay Tunneling support, SR-IOV enablement for Nova Lake Xe3P graphics and a Sandy Bridge-era fix. NVIDIA work continues in two tracks: developers keep building the Nova Rust driver toward Hopper and Blackwell support, while Nouveau gains GA100 accelerator support.

DRM core now defaults to the fair scheduler. That change affects how the kernel arbitrates GPU jobs among clients. Desktop users may notice it only under load, but multi-tenant GPU systems and busy compositor workloads give scheduler changes more room to show up in latency and throughput tests.

Build recommendations

Radeon HTPC builders should wait for AMD to enable HDMI 2.1 FRL by default before they rebuild a machine around this feature. Linux 7.2 marks progress, but a living-room PC needs predictable 4K 120 Hz, VRR and audio behavior more than it needs an early kernel flag.

Workstation users with HDMI-only monitors should track Linux 7.2 and the next AMDGPU cycles. If your display also supports DisplayPort, DisplayPort remains the cleaner high-refresh path today. If your display exposes its best modes only over HDMI, this merge gives you the first upstream sign that AMD has moved the open driver toward parity.

Homelab users who pass Radeon cards through to Linux guests should test with care. FRL, display power management and page-size fixes touch different parts of the stack, and each one can affect boot consoles, suspend behavior or monitor detection. Keep a known-good kernel installed, record EDID output before and after the upgrade and compare power draw at the wall.

Developers can follow the kernel work through kernel.org and the DRM subsystem documentation in the Linux kernel tree. AMDGPU users who test release candidates should also watch the Mesa and freedesktop.org DRM channels, because display fixes often span kernel, user space and compositor code.

Linux 7.2 does not finish Radeon HDMI 2.1 support, but AMD has now put the first FRL code upstream. For builders with HDMI 2.1 displays, that gives the next kernel cycles a concrete feature to test instead of a long-standing gap to track.