AMD is unable to release an open-source HDMI 2.1 implementation after the HDMI Forum rejected its proposal; the forum closed public specification access in 2021

One of the limitations of AMD's open-source Linux graphics driver has been the inability to implement HDMI 2.1+ functionality …

Phoronix 2024-03-03 Michael Larabel

Context & Ripple Effects

HDMI 2.1 was introduced as a higher-bandwidth display standard with features including variable refresh rate, making it a consequential capability target for graphics drivers. The subsequent HDMI 2.1a update underscored that the standard was continuing to evolve.

The Forum's 2021 decision to close public specification access turned implementation knowledge into a controlled input. AMD's rejected proposal makes that access boundary directly consequential for the open Linux driver.

First-order effects

AMD cannot upstream an open-source implementation of HDMI 2.1+ functionality for its Linux graphics driver under the Forum's current terms.
Linux users and downstream distributions relying on AMD's open driver remain unable to receive that functionality through the open driver stack.

Second-order effects

Open-driver maintainers must continue to treat HDMI capability parity as dependent on standards-holder access rather than solely on engineering work.
The decision increases the practical advantage of display stacks that can obtain or ship implementations under the Forum's licensing and specification-access model.

Third-order effects

If more interface standards restrict specification access, open-source hardware support may fragment around the features whose implementation details are controlled by consortia.
This is a governance issue as much as a technical one: standards bodies can determine which capabilities are broadly implementable, potentially making proprietary access a durable form of platform differentiation.

The trend: The episode is part of a broader shift in which access rules around technical specifications increasingly shape whether open-source ecosystems can match proprietary platform capabilities.

Discussion

@tekwendell Wendell on x
Vote with your wallets folks. This is abaolute lunacy from the hdmi forum imho
@kazini1 George Larkin on x
Very Evident that @HDMIForum is more worried about money than the future of the technology. They preach about the future of HDMI tech but this is a clear move to show otherwise.
@svelle1 Sven on x
Really disappointed to hear about this backward-thinking decision by the HDMI Forum. Big props to the AMD folks trying to push this through all this time, though. https://arstechnica.com/...
@mikepengellyca Mike Pengelly on x
Seems like it is time to reject every closed standard. If HDMI can be this problematic, then there is no limit. Open Standards Now @HDMIForum should be ashamed.
@steipete Peter Steinberger on x
“The HDMI Forum has rejected our proposal unfortunately. At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements.” https://arstechnica.com/...
@ffomine @ffomine on x
One of the limitations of AMD's open source Linux graphics driver was the inability to implement HDMI 2.1+ functionality based on the legal requirements of the HDMI Forum. AMD engineers worked with the HDMI Forum on a solution that would enable the capabilities of the HDMI 2.1+
@cavaliermarty @cavaliermarty on x
Wow, why bother using HDMI if the HDMI forum is going to be a big baby about open source drivers
@thomasafine @thomasafine on x
The HDMI Forum can just fuck right off. Proprietary standards are not standards. Where do I sign up to reverse engineer HTMI 2.1 and create a Linux driver? https://arstechnica.com/...

Chronicles