HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec
HDMI licensing rules are preventing AMD from open-sourcing its HDMI 2.1 driver for Linux, because the HDMI Forum’s membership and trademark agreements prohibit publishing a compliant implementation under an open license. Commenters argue this entrenches DRM-heavy, proprietary standards and undermines open ecosystems, while noting that trademarks like “HDMI” also complicate third‑party or reverse‑engineered solutions. Many see DisplayPort (and USB‑C with DP alt mode) as a more open, technically superior alternative, though HDMI’s entrenched position in TVs and consumer devices makes it hard to displace.
Legal and Licensing Constraints
- HDMI Forum membership appears to bar AMD from releasing an open-source HDMI 2.1 implementation based on the official spec; doing so would likely breach contract and IP terms.
- HDMI is trademarked; members license both spec and logo. Non‑members could theoretically implement a compatible stack but could not market it as “HDMI compliant.”
- Debate over trademark scope: some say phrases like “HDMI-compatible” should be allowed as nominative use, similar to “compatible with macOS” or “IBM-compatible.” Others think rights holders could still litigate, even if they’d likely lose.
- Some view exposure to the proprietary spec as “poison” that prevents sharing source under open licenses.
Reverse Engineering and Practicality
- One camp argues a non‑member could clean-room or reverse-engineer HDMI 2.1 (from traffic, binaries, etc.) and publish an open driver.
- Others say sniffing a 48 Gbit/s link is impractical without extremely expensive equipment; counter-arguments claim it’s feasible with relatively cheap logic analyzers and protocol knowledge.
- Legal status of reverse‑engineered contributions to AMD’s kernel driver is seen as more plausible than reading the spec directly, but still politically risky for AMD.
Workarounds and Alternatives
- Closed-source drivers (e.g., from other GPU vendors) already support high-res, high-refresh HDMI on Linux; this undercuts claims that “Linux users are out of luck.”
- Users suggest active adapters (USB‑C/DP → HDMI), docks, and DP-to-HDMI dongles as workarounds. Some report HDMI 2.1 features like VRR working via certain chipsets, others note bandwidth/refresh limits and mixed reliability.
- Many recommend avoiding HDMI altogether: use DisplayPort or USB‑C with DP Alt Mode where possible.
HDMI vs DisplayPort, DVI, and TV Ecosystem
- Several participants praise DisplayPort as technically superior, royalty‑free, and better aligned with PCs, while lamenting HDMI’s DRM baggage (HDCP) and licensing.
- Others recall DVI fondly (simple, reliable, though bulky) and note its own HDCP support.
- TVs overwhelmingly ship with HDMI only; reasons cited include ecosystem inertia, consumer expectations, and compatibility with consoles and media devices. DP on TVs is seen as unnecessary cost for mass-market buyers.
DRM, Control, and “War on General-Purpose Computing”
- HDMI/HDCP restrictions are framed as part of a broader push by media and platform companies to control playback environments, lock users into specific OSes/hardware, and resist open standards.
- Some argue DRM doesn’t stop determined pirates but degrades legitimate user experience and pushes people toward piracy for reliability.
- Virtualization, GPU passthrough, and bus capture are mentioned as ways sophisticated users can still obtain unencrypted content.
Open Standards and Governance
- Participants ask why displays rely on proprietary or paywalled standards when many industries use (at least nominally) open standards.
- Others respond that creating a truly open, financially sustainable standards body with broad industry buy‑in is difficult; many standards organizations fund themselves via paywalled documents, which clashes with open-source norms.
- Some see HDMI Forum’s hostility to open implementations as rent‑seeking and a red flag for insufficient public scrutiny of the spec.