Experimental Out-Of-Tree Code Aims To Provide HDMI 2.1 FRL For AMD Linux Driver

One of the long-standing limitations of the AMDGPU Linux kernel graphics driver has been its lack of support for HDMI 2.1 and later specifications. While AMD has expressed interest in supporting HDMI 2.1+ functionality under Linux, the company has been legally blocked by the HDMI Forum from implementing these features in their open-source driver.

However, independent developers have taken matters into their own hands. Beyond the previously reported HDMI Gaming Features work being done independently using public code, knowledge, and trial-and-error approaches, a new development has emerged. Today, an independent developer announced what they describe as "working" HDMI 2.1 Fixed Rate Link (FRL) support for the AMDGPU driver.

The developer has published a kernel tree on GitHub containing HDMI FRL support that successfully enables HDMI 2.1 bandwidth for AMD GPUs. According to the developer, the HDMI 2.1 bandwidth work is successfully using FRL training, HDR functionality works, and other basic features appear operational. However, testing has been limited to a single graphics card - the Radeon RX 9070 XT.

Several features remain unimplemented, including Display Stream Compression and YCbCr 4:2:0 support. The independent developer created these patches through a methodical approach: analyzing differences in Radeon GPU register states between Windows and Linux implementations, closely examining Windows driver behavior, and incorporating insights gained from studying AMD-Xilinx HDMI FRL training code.

Those interested in experimenting with these experimental, out-of-tree patches can find them in the developer's GitHub repository. Additional details about the effort are available in a Reddit thread that was started today.

While this work represents an impressive achievement by passionate open-source developers, it's unlikely to yield immediate improvements for the broader AMD Radeon Linux user base. The patches would not be accepted for upstreaming to the AMDGPU driver for several reasons: the HDMI Forum has already rejected such implementations, and any code would need to clear AMD's legal review process.

The situation highlights the ongoing tension between open-source development and proprietary standards organizations. It may help apply pressure on the HDMI Forum to reconsider their policy, particularly if stakeholders like Valve become involved. However, this has been an unfortunate issue plaguing AMD Linux users for years already.

For now, AMD Linux users are best advised to use DisplayPort where possible, as it doesn't face the same legal restrictions. Alternatively, future AMD GPUs might see more HDMI display functionality moved into binary firmware blobs, which would make implementation easier for open-source drivers while technically complying with HDMI Forum restrictions.

The work demonstrates the ingenuity of the open-source community in working around artificial limitations, but also underscores the challenges faced when proprietary standards organizations restrict implementation of widely desired features in open-source ecosystems.