Good news for Linux gamers and the upcoming Steam Machine, as it appears the AMD GPU kernel drivers are expanding their HDMI 2.1 support even further.
Previously we had patches submitted to the Linux kernel to enable HDMI FRL (Fixed Rate Link) support, but these patches have been revised with version 3 now also bringing DSC (Display Stream Compression). Together, if approved and accepted into the Linux kernel, they should really help AMD HDMI support higher resolutions and refresh rates which has been quite the missing link for AMD + Linux on the open source Mesa drivers.
From the kernel mailing list:
This patch series adds HDMI FRL and FRL DSC support to the amdgpu display driver.
This work passed a representative subset of HDMI compliance and a full compliance run on this branch is in the works. We don't expect the full run to show any failures since it passes in other environments.
Thanks to Siqueira who prepared this work a couple years back and unfortunately didn't manage to send them while he was still working at AMD.
Thanks to Jerry who has been making this code solid on Linux and running the compliance tests.
The first patch in the series isn't related to HDMI 2.1 but included here because it moved the code around some key bits of the HDMI 2.1 stuff around too much. It will land with the next DC Patch series.
v3:
- Add missing DML2 bits
- Merged register headers to asdn and removed from patchsetv2:
- Add missing function pointers on DCN 3.x
- Add DSC
This will be a really great boost for Linux (and not just for gaming) if the patches get fully accepted, to see in a future Linux kernel release which would most likely be kernel 7.2 since 7.1 is already in the release candidate stage. So we might see this actually available in the second half of 2026.
Article taken from GamingOnLinux.com.
See more from me
You can also find comments for this article on social media: 
Even worse is that these mailinglists are publicly archived with full names and e-mail-adresses.
Why not keep that to those that subscribed and not let harvesters access them?
Where are the gitlabs and githubs and modern infrastructure? ;)
Quoting: tpauIt is incredible that this development still relies on files exchanged over e-mail.If a process has been working for this long, why change it? Besides, emails are still a good way to leave paper trails in case anyone wants to go back to see what conversations have been going on during the development process. Using modern infrastructure doesn't guarantee that every conversation will be available forever because all of it can go away if no backup (or the backup got deleted) was done to preserve it in the event the repository or other modern tools ceased to exist.
Even worse is that these mailinglists are publicly archived with full names and e-mail-adresses.
Why not keep that to those that subscribed and not let harvesters access them?
Where are the gitlabs and githubs and modern infrastructure? ;)
PlayingOnLinuxphone 10 hours ago
Quoting: BumadarI can't really find how they got passed thr HDMI Forum licensing?My guess: HDMI 2.2 will be the new "no license" situation. HDMI 2.1 has a data transfer rate of 4k @120Hz and some monitors already allow 4k @240Hz (which DisplayPort can handle btw). So there is a good argument for companies to implement HDMI 2.2 and pay for it (even if it is just for advertisement). I think they only want to get payed for the newest license. This way they allow older specs to be implemented, which strengthens their market position (better have it build in everywhere to be present everywhere than taking the last cents they can get).
I also assume that this old style approach deters people from joining eventually.
On the actual topic.
Do we have most of the HDMI 2.1 spec covered by now or is there anything else missing?
Quoting: BumadarI can't really find how they got passed thr HDMI Forum licensing?Most likely someone at HDMI Forum finally realized that an open source implementation is not the danger to their business model that they first thought. And this was true the entire time, just that they had to figure it out, their business model is selling a license to carry the HDMI2.1 label and that you have to do regardless of where your implementation comes from and regardless of if its open or closed.
Quoting: PlayingOnLinuxphonePayment was never the issue though and AMD is and have been for years a HDMI licensee. There is nothing with these patches that would or could make HDMI Forum not get payed exactly what they where payed before.Quoting: BumadarI can't really find how they got passed thr HDMI Forum licensing?My guess: HDMI 2.2 will be the new "no license" situation. HDMI 2.1 has a data transfer rate of 4k @120Hz and some monitors already allow 4k @240Hz (which DisplayPort can handle btw). So there is a good argument for companies to implement HDMI 2.2 and pay for it (even if it is just for advertisement). I think they only want to get payed for the newest license. This way they allow older specs to be implemented, which strengthens their market position (better have it build in everywhere to be present everywhere than taking the last cents they can get).
Last edited by F.Ultra on 12 May 2026 at 10:36 pm UTC
Quoting: F.UltraPayment was never the issue though and AMD is and have been for years a HDMI licensee. There is nothing with these patches that would or could make HDMI Forum not get payed exactly what they where payed before.I think the logic (from an artificial scarcity hoarding viewpoint) was that if they didn't keep the spec super secret, companies could just make stuff without giving them money. Which they didn't like the sound of. But, as you say, you still need to give them money (and AMD did) for the compliance tests and the sticker, and that's where the prestige is. "Proper" hardware companies will still give them money to remain "proper," and fly-by-night won't-conform-to-the-spec companies weren't going to give them money either way.
Patreon
PayPal
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck