HDMI 2.1 FRL open source headaches, and how FRL is never coming to Linux

Remember when Gigabyte monitors were forced to 24Gbps? This is because they were not allowed to view the HDMI FRL spec from the HDMI forum. It’s a substantial upcharge and ongoing licensing cost to view the heavily NDAed FRL spec in full and implementation is just like MPEG LA HEVC licensing so both AMD and NVIDIA decided to not support FRL in Linux GPU drivers.

This will never be solved because FRL is a closely guarded trade secret (think ITARs with military tech, and KFC’s herbs and spices) and both monitor manufacturers don’t want to pay for the NDAs and open source projects don’t want to use license and patent encumbered stuff in their code, like exFAT. HDMI licensing had to kinda do this because of the flood of grey market splitters, and tighten their NDA agreements so much that it makes it impossible to work with if you’re not a close to or over a billion dollar company with extremely high volumes. The new spec also updates licensing terms for existing HDMI 2.0 by making it 2.1, trying to end manufacture of 2.0 devices so they could go after the grey market easier.

This sadly also means friction for HDMI 2.1 capture cards because the only ones able to pay the licensing might have to pass that along so that HDMI 2.1 capture cards cost $2000-$3000 for full 48Gbps. (Datapath VisionSC cards for instance, Digital Foundry can afford that, you can’t)

Unfortunately, like HDR on Linux, this is going to remain unchanged for a very long time.

NVIDIA has some HDMI2.1 code in their open-source drivers. Could provoke the topic to be opened up and maybe get some movement to open-source support down the line.

Or just lawsuits, probably lawsuits because MONEY!

I am maybe going to do a video on this and would appreciate some more research help.

The HDMI 2.1 stuff in nv driver is mostly interface to an opaque blob from what I can tell.

2 Likes