Phoronix first reported the September 17 AMDGPU submission, and the public DRM mailing-list record from AMDGPU maintainer Alex Deucher confirms the scope: the batch contains an explicit “Fix HDMI FRL audio enable” change, FRL capability-check cleanups, and new kernel unit tests covering HDMI connector initialization, FreeSync capability updates, FRL bandwidth lookup, and Display Stream Compression configuration. This is not a fresh announcement that HDMI 2.1 will arrive in Linux; it is a corrective follow-up to the larger Linux 7.4 work AMD submitted a week earlier.
The distinction matters to anyone planning a Linux gaming PC around an AMD card and a living-room display. The audio correction addresses a basic part of HDMI operation that can fail independently of video output. A system can negotiate a high-bandwidth image successfully yet still mishandle audio enablement, turning what looks like a successful HDMI 2.1 rollout into a poor replacement for a console or Windows gaming setup.
The FRL switch is becoming usable, not merely present
Fixed Rate Link, or FRL, is the higher-bandwidth signaling method introduced with HDMI 2.1. It is the piece required when display modes exceed the practical limits of older HDMI TMDS signaling, particularly for high-refresh 4K output and combinations of high resolution, color depth, and chroma quality. It is also only one part of a modern television setup: a usable implementation needs correct display negotiation, audio behavior, variable refresh handling, and low-latency mode support.
AMDGPU gained initial FRL support in Linux 7.2, but it was deliberately disabled by default. Earlier reporting by Phoronix documented why: enabling FRL without HDMI variable refresh rate support risked taking away capabilities some users already had with their displays. Testers could turn it on through an AMDGPU display feature-mask kernel parameter, but that was an interim route intended for users who accepted the risk of regressions.
The first AMDGPU feature pull for Linux 7.4 changed that policy. It included HDMI 2.1 FreeSync, VRR, and Auto Low Latency Mode support, then enabled FRL by default. The September 17 follow-up does not reverse that decision. Instead, it supplies an audio enable fix and expands test coverage in the display code, including checks for FRL bandwidth calculations and HDMI-specific connector setup.
That sequencing is more revealing than the headline. AMD is attempting to close the gaps that made a default-on deployment unsafe rather than treating the initial kernel support as complete. The large new KUnit test additions are particularly relevant: display regressions tend to appear as combinations of GPU, cable, receiver, monitor firmware, refresh rate, and suspend/resume behavior that are expensive to catch after a distribution ships a kernel.
Audio is the immediate fix, while testing is the larger signal
The public patch list identifies the relevant correction as drm/amd/display: Fix HDMI FRL audio enable. AMD has not published a consumer-facing description of the failure mode, the exact Radeon generations affected, or a list of displays or AV receivers that reproduce it. That omission means users should not assume every HDMI audio issue on an AMD Linux system traces back to this patch; audio routing, PipeWire configuration, receiver handshakes, and display firmware can all produce similar symptoms.
Still, the location of the fix matters. It sits in the AMD display driver’s FRL path, alongside changes spanning FRL stream encoders for multiple display-engine generations. The mailing-list record shows modifications to the DCN 3.0, DCN 4.2, and DCN 6.0 FRL encoder code, even though AMD has not released a clear supported-product matrix for the proposed Linux 7.4 implementation.
The testing changes go further than one audio bug. They add or expand tests for HDMI connector initialization, FreeSync capability handling, FRL bandwidth lookup, DSC capability validation and configuration calculation, and DisplayPort Multi-Stream Transport behavior. In plain terms, AMD is exercising the logic that decides what a display can do before the driver commits to a mode.
That is valuable because the visible user complaint from a bad display stack is usually deceptively simple: a 4K television falls back to 60 Hz, VRR disappears from the desktop settings, an HDR-capable display gets an unwanted pixel format, or audio vanishes after a mode switch. The source of the failure may be a bandwidth computation, connector capability parsing, or state-update ordering deeper in the driver. More coverage will not guarantee compatibility with every TV, but it reduces the chance that common paths remain untested simply because the initial FRL enablement worked on a limited setup.
AMD has not named the “upcoming hardware”
The same pull request contains changes for GFX12.1 graphics, Display Core Next 6, and other as-yet-unmapped IP blocks. The code list also includes a DCN 6 initialization fix, cleanup of a legacy MES design for GFX12.1, and AMDKFD fixes for GFX12 and GFX12.1. These are legitimate signs that AMD’s Linux driver work is tracking hardware beyond its currently detailed public product lineup.
They are not confirmation of a specific Radeon product, launch date, or feature set. AMD did not provide PCI device IDs, retail names, board partners, availability dates, or a statement tying GFX12.1 and DCN6 to a named RDNA generation in this submission. Calling the patches proof of a particular upcoming GPU would go beyond the record.
There are also fixes with more immediate consequences for existing systems. The bundle addresses GPU PCIe link-capability reporting, retains a runtime power-management reference for peer-to-peer DMA-BUF attachments, repairs an AMDKFD partitioning lock issue, adds boundary checks, and changes SDMA reset and recovery logic. For RDNA1-era GFX10 and GFX10.3 hardware, the AMDKFD component gains compute-unit occupancy reporting and disables GFXOFF when that reporting is in use.
That last item is chiefly a development and compute-management feature rather than a desktop gaming upgrade. Compute-unit occupancy measures how fully GPU execution resources are being used, information that can aid profiling and scheduling analysis. The accompanying GFXOFF change signals a power-management tradeoff: AMD is preserving the state needed for reliable occupancy reporting rather than allowing the graphics block to enter that low-power state freely.
This is a submitted feature batch, not Linux 7.4 itself
The current code has been sent to DRM-Next, the graphics development branch that feeds the kernel merge process. It has not yet become a final Linux 7.4 release, and a pull request can still be revised, split, or rejected before inclusion. The Linux 7.4 merge window is expected to open in the second half of October 2026, after Linux 7.3 reaches a stable release.
That timing creates two practical tracks for users. Early adopters who build kernels or use distributions that package drm-next material can test the changes before the stable release, but should expect normal development-kernel risk. Everyone else should wait for their distribution to ship Linux 7.4 or backport selected display patches; stable distro kernels often arrive weeks or months after upstream releases, especially in enterprise distributions.
For administrators, this is not a reason to deploy a development kernel merely to obtain HDMI 2.1. The better operational move is to inventory machines where Radeon graphics are connected through HDMI 2.1 displays, AV receivers, docks, or USB4 display paths, then watch distribution kernel release notes for the eventual backport. Those are the configurations most likely to benefit, and the ones most likely to expose interoperability edge cases.
AMD’s September 17 submission expands across 248 files, with 9,549 insertions and 4,965 deletions, so this is far broader than one HDMI patch. But the FRL audio repair is the user-facing item to watch: Linux 7.4’s planned default enablement will be judged less by whether it can produce a high-refresh picture than by whether Radeon systems keep video, VRR, low-latency mode, and audio working together over the HDMI cable already connected to the display.