HDMI 2.1 unter Linux: DRM/KMS, Lizenzblockade und was Steam Deck-Nutzer jetzt tun können

Wer unter Linux eine AMD- oder Nvidia-GPU mit HDMI-2.1-Port betreibt und am 4K-TV auf 120 Hz hofft, stößt auf eine unbequeme Wahrheit: Der Port funktioniert, aber meist nur im HDMI-2.0-Modus mit maximal 4K bei 60 Hz. Warum das so ist, was der DRM/KMS-Stack damit zu tun hat, was Valve wirklich vorantreibt und welche Optionen heute tatsächlich funktionieren – das schauen wir uns technisch nüchtern an.

Das Kernproblem: HDMI 2.1 am Port, HDMI 2.0 im Treiber

Das Szenario ist frustrierend und häufig: Eine RX 7900 XT, ein HDMI-2.1-Kabel, ein moderner TV – und Linux liefert über HDMI maximal 4K bei 60 Hz. Unter Windows läuft dasselbe Setup mit 120 Hz oder mehr. Ist die Hardware defekt? Nein. Der Unterschied liegt vollständig im Treiber-Stack.

HDMI 2.1 führt mit FRL (Fixed Rate Link) eine neue physische Übertragungsschicht ein, die deutlich höhere Bandbreiten ermöglicht als der ältere TMDS-Modus. TMDS ist der Signalweg, den HDMI 1.4 und 2.0 nutzen, und er ist bei 18 Gbit/s limitiert – das reicht für 4K/60 Hz, aber nicht für 4K/120 Hz ohne Kompression. FRL skaliert bis 48 Gbit/s und macht erst die hohen Bildraten und Auflösungen möglich, die HDMI 2.1 verspricht. Die freien Desktop-GPU-Treiber im Linux-Kernel sprechen HDMI-Ports bislang überwiegend im TMDS-Modus an. FRL-Betrieb fehlt in den Upstream-Treibern für AMDGPU, i915 und den offenen Nvidia-Treiber.

Das ist keine Sabotage. Es ist ein Lizenzproblem.

DRM/KMS: So ist HDMI im Linux-Grafikstack verankert

Der Linux-Grafikstack basiert auf DRM/KMS (Direct Rendering Manager / Kernel Mode Setting). KMS übernimmt die Display-Ansteuerung ab Kernel-Ebene: Auflösung, Refresh-Rate, Connector-Eigenschaften, EDID-Parsing. Jeder GPU-Treiber – AMDGPU, i915, nouveau, aber auch eingebettete SoC-Treiber – implementiert einen oder mehrere Connector-Typen, darunter HDMI. Die offizielle Kernel-Dokumentation zu DRM/KMS beschreibt dabei auch HDMI-2.1-spezifische Strukturen wie DSC-Fähigkeiten (Display Stream Compression) für HDMI-Sinks – konzeptionell ist der Stack also vorbereitet.

In der Praxis existiert vollständige HDMI-2.1-Unterstützung mit FRL im Mainline-Kernel bislang nur für spezialisierte SoC-Designs. AMD-Entwicklungsplattformen von Xilinx beispielsweise – Zynq UltraScale+ MPSoC und Versal Adaptive SoC – bringen einen eigenen HDMI-2.1-TX-Subsystem-Treiber mit, der explizit FRL, DSC und höhere Bandbreiten abdeckt. Das ist kein Desktop-GPU-Treiber, sondern ein eingebetteter Subsystem-Treiber für ganz spezifische Hardware. Desktop-GPUs von AMD, Intel und Nvidia haben das nicht im Upstream.

Was bedeutet das praktisch? Der KMS-Stack kann HDMI 2.1 grundsätzlich ausdrücken. Aber ein Treiber muss FRL erst implementieren, und genau da hört es für freie Desktop-GPU-Treiber auf.

Lizenz vor Technik: Warum das HDMI Forum bremst

HDMI ist kein offener Standard. Das HDMI Forum verwaltet das Protokoll und verlangt von Mitgliedern Lizenzgebühren sowie die Einhaltung spezifischer Bedingungen. Eine vollständige, offene Referenzimplementierung von FRL zu veröffentlichen, kollidiert mit diesen Lizenzbedingungen. GPU-Hersteller wie AMD, die Mitglied im HDMI Forum sind, können die nötige Implementierung intern entwickeln, aber als Open-Source-Code freigeben ist rechtlich heikel.

Genau das ist der Unterschied zu DisplayPort: DisplayPort basiert auf einem offenen VESA-Standard, der freie Implementierungen ausdrücklich erlaubt. Das ist der Hauptgrund, warum Adaptive Sync, hohe Auflösungen und Refresh-Rates über DisplayPort unter Linux seit Jahren stabil funktionieren – und HDMI 2.1 hinterherhinkt.

Ein Entwickler hat das eindrücklich gezeigt: Inoffizielle FRL-Patches für den AMDGPU-Treiber existieren, basieren auf Reverse Engineering (Vergleich von Register-Zuständen unter Windows und Linux) und unterstützen FRL-Training, Video, Audio, HDR, VRR sowie Hotplug. In der Community-Diskussion dazu wurde schnell klar: Die Hardware kann FRL. Der Treiber wird nur nicht offiziell freigegeben. Diese Patches sind nicht im Mainline-Kernel, nicht von AMD rechtlich abgesichert und nicht flächendeckend auf verschiedenen GPU-Generationen und TV-Modellen getestet. Wer sie als AUR-Paket installiert, experimentiert.

Valve, AMDGPU und das Steam Deck: Was wirklich stimmt

Valve engagiert sich intensiv im Linux-Grafikstack. Das ist belegt und konkret: Mesa, RADV, AMDGPU-Patches, Proton-Infrastruktur, SteamOS – Valve bringt regelmäßig Code in den Upstream-Kernel ein, profitiert direkt von einem stabilen, leistungsfähigen freien Grafikstack und hat ökonomisches Interesse daran, dass Linux als Gaming-Plattform funktioniert.

Allerdings: Konkrete HDMI-2.1-FRL-Patches von Valve, die öffentlich isolierbar und belegbar sind, existieren zum jetzigen Stand nicht in leicht zugänglichen Quellen. Die Schlagzeile „Valve treibt HDMI-2.1-Patches voran“ ist vorsichtig zu formulieren. Was Valve vorantreibt, ist der breite Upstream-Stack – VRR, HDR-Vorbereitung, AMDGPU-Stabilität, Display-Pipeline-Fixes. Davon profitiert auch HDMI langfristig, aber FRL-Support ist nicht das erklärte Projektziel.

Das Steam Deck ist außerdem primär ein DisplayPort-Gerät. Der USB-C-Anschluss nutzt DP-Alt-Mode. Wer das Deck an einen 4K-TV anschließt, tut das über ein Dock – und viele Docks setzen intern auf DP-Alt-Mode plus einen DP-zu-HDMI-Konverter-Chip. Aus Sicht des Kernel-Treibers wird dann DisplayPort angesteuert, nicht HDMI-FRL. Dieses Muster ist auch für Desktop-GPUs relevant.

Die Dongle-Lösung: Pragmatisch und heute funktionierend

Intel nutzt bei einigen Plattformen intern einen DP-zu-HDMI-2.1-Konverter im Port selbst. Das Prinzip ist dasselbe: Aus Linux-Sicht wird DisplayPort angesteuert, der Konverter-Chip übernimmt die FRL-Aufbereitung Richtung TV. Für Nutzer, die einen AMD- oder Nvidia-GPU-Ausgang über HDMI an einen 4K-TV mit 120 Hz anschließen wollen, ist heute ein aktiver DP-zu-HDMI-2.1-Adapter oft der pragmatischste Weg.

Solche Adapter – von Herstellern wie Club 3D, Cable Matters oder ähnlichen – übernehmen FRL auf Hardware-Ebene, sprechen zum GPU-Treiber hin DisplayPort und ermöglichen dadurch 4K bei 120 Hz plus VRR über HDMI, selbst wenn der GPU-Treiber kein natives FRL spricht. In der Level1Techs-Community ist die Empfehlung klar: DisplayPort bevorzugen, und wenn HDMI nötig ist, einen aktiven Adapter einsetzen.

Das klingt nach Workaround – und das ist es auch. Aber es ist einer, der heute stabil funktioniert, ohne Kernel-Patches, ohne AUR-Experimente und ohne Lizenzgrauzone. Ich halte das für den realistischeren Rat für Desktop-Linux-Gamer als auf Upstream-HDMI-2.1-Support zu warten, dessen Zeitplan offen ist.

Nvidia: Proprietär hilft, Open-Source nicht

Beim proprietären Nvidia-Treiber unter Linux funktioniert HDMI 2.1 in der Praxis besser – Nvidia kann als HDMI-Forum-Mitglied eine lizenzierte Implementierung in den closed-source Treiber einbauen. Der offene Nvidia-Treiber (nouveau, aber auch die neueren Open-Source-Kernel-Module) ist hier genauso limitiert wie AMDGPU: HDMI läuft im 2.0-Modus, 4K bei 60 Hz. Für High-Refresh-Rate-Gaming über HDMI unter Linux mit offenem Treiber ist Nvidia derzeit keine Lösung. Die Empfehlung gilt auch hier: DisplayPort oder aktiver Adapter.

Das zeigt das strukturelle Muster: Wer proprietäre Treiber nutzt, kann HDMI-2.1-Features teils nutzen, weil der Hersteller die Lizenzfrage intern löst. Wer auf den freien Stack setzt – was für Linux-Nutzer in der Regel die korrekte Entscheidung ist –, zahlt den Lizenz-Preis an anderer Stelle.

Was HDMI 2.1 eigentlich bedeutet – und was nicht

Ein häufiger Denkfehler: „HDMI 2.1″ ist kein atomares Feature. Der Standard umfasst FRL, DSC, eARC, VRR über HDMI (auch bekannt als ALLM, QMS), HDR-Transport und mehr. Viele TV-Hersteller werben mit „HDMI 2.1″, implementieren aber nur Teilmengen davon. Ebenso unter Linux: VRR über HDMI kann unter bestimmten Bedingungen funktionieren, auch ohne FRL, wenn beide Seiten es unterstützen. Wer nur VRR auf einem Monitor will, ist möglicherweise besser dran als gedacht – oder schlechter, je nach konkreter GPU-TV-Kombination.

Für den Artikel-Kontext bedeutet das: Nicht jedes Upgrade auf „HDMI 2.1″ löst das Bandbreiten-Problem für 4K/120 Hz. FRL ist das eigentliche Engpass-Feature, und das ist es, was im freien Kernel-Stack fehlt. DSC (Display Stream Compression) könnte theoretisch helfen, 4K/120 Hz auch über TMDS zu übertragen, ist aber ebenfalls nicht vollständig im freien Stack für Desktop-GPUs implementiert.

Warum das Problem über Gaming hinausgeht

Die HDMI-2.1-Lücke im freien Linux-Stack betrifft nicht nur Gamer. Wer Linux als Desktop-Betriebssystem für kreatives Arbeiten, Video-Editing oder schlicht als primäres Wohnzimmer-Betriebssystem an einem modernen 4K-TV einsetzt, läuft in dieselbe Wand. Ein Filmschnitt-Workflow, der 4K-Material mit hoher Framerate im nativen Modus darstellen soll, profitiert genauso von FRL wie ein Spiel. Ebenso Home-Theater-PC-Setups, die unter Linux mit Kodi oder Jellyfin betrieben werden und HDR-Passthrough über HDMI an AVR oder Soundbar ausliefern sollen.

Gerade das eARC-Feature – Enhanced Audio Return Channel – ist für solche Setups relevant. eARC ist ebenfalls Bestandteil des HDMI-2.1-Standards und ermöglicht verlustfreies Mehrkanal-Audio zurück vom TV an einen angeschlossenen AV-Receiver. Auch hier ist die Unterstützung im freien Stack fragmentiert. Wer unter Linux einen HTPC aufbaut und sein Heimnetzwerk oder Mediacenter selbst einrichten möchte, wird feststellen, dass eARC-Funktionalität je nach Hardware-Kombination und Treiber-Version mehr oder weniger zuverlässig ist. Der proprietäre Nvidia-Treiber schneidet auch hier besser ab als die offenen Alternativen – auf Kosten der Treiber-Freiheit.

Die Lizenzbarriere des HDMI Forums trifft also eine breite Nutzerschicht: von Gamern über Content-Creator bis hin zu Heimkino-Enthusiasten. Solange FRL nicht offiziell und lizenzkonform im freien Stack landet, bleibt das ein strukturelles Defizit von Linux als Wohnzimmer-Plattform.

Wie ein Upstream-Patch realistischerweise entstehen könnte

Es gibt grundsätzlich drei Wege, wie FRL-Support in den Mainline-Kernel gelangen könnte. Erstens könnte das HDMI Forum seine Lizenzbedingungen anpassen und eine Open-Source-konforme Implementierung ausdrücklich gestatten. Das wäre der sauberste Weg, erscheint aber politisch unwahrscheinlich, solange keine größeren wirtschaftlichen Druckverhältnisse entstehen. Zweitens könnte ein Hardware-Hersteller – AMD wäre der naheliegendste Kandidat – intern eine lizenzierte FRL-Implementierung entwickeln und diese als dual-lizenziertes Modul zur Verfügung stellen, ähnlich wie Firmware-Blobs für Wireless-Karten. Das ist ein bekanntes Muster im Linux-Kernel-Ökosystem und würde das Lizenzproblem pragmatisch umgehen, ohne die Lizenzbarriere selbst zu schleifen.

Drittens – und das ist die Community-Route – könnten Reverse-Engineering-basierte Patches ausreichend reifen, um stabil, breit getestet und rechtlich vertretbar in einen externen Kernel-Tree aufgenommen zu werden, ähnlich wie es bei anderen proprietären Protokollen in der Vergangenheit geschehen ist. Dieser Weg ist der langsamste und risikoreichste, hat aber historisch bei anderen Standards Früchte getragen.

Welcher Weg sich durchsetzt, ist offen. Alle drei erfordern entweder politischen Willen beim HDMI Forum, wirtschaftliches Kalkül bei den Herstellern oder erhebliche Entwicklungsarbeit in der Community. Ein konkreter Zeitplan existiert für keinen der drei Pfade.

Handlungsempfehlungen für heute

Was tun, wenn man jetzt 4K bei 120 Hz oder 1440p bei 144 Hz unter Linux will?

• DisplayPort bevorzugen. Wenn Monitor und GPU DP anbieten, ist das die reibungsloseste Lösung. Adaptive Sync, hohe Auflösungen, hohe Refresh-Rates – alles funktioniert im freien Stack ohne Lizenz-Stolpersteine.
• Aktiver DP-zu-HDMI-2.1-Adapter für TV-Setups. Wer einen 4K-TV ohne DisplayPort-Eingang hat, nutzt einen aktiven Adapter mit FRL-Chip. Das funktioniert heute mit AMDGPU und Mesa ohne Patches.
• Steam Deck über USB-C-Dock. Dock mit DP-Alt-Mode und HDMI-2.1-Ausgang wählen. Nicht auf „HDMI 2.1 nativ“ im Deck-Treiber verlassen.
• Inoffizielle FRL-Patches nur für Experimentier-Setups. Wer auf AMDGPU die AUR-Patches testet, sollte das auf einem Nicht-Produktiv-System tun. Stability und Support-Niveau sind unklar.
• Proprietären Nvidia-Treiber, wenn HDMI zwingend nötig. Wer ausschließlich einen HDMI-2.1-TV hat und Nvidia-Hardware, kommt mit dem proprietären Treiber weiter – aber das ist ein Kompromiss am anderen Ende der Freiheitsskala.
• HTPC und eARC-Setups realistisch einschätzen. Wer eARC für Mehrkanal-Audio über HDMI benötigt, sollte die konkrete GPU-TV-Kombination vor dem Kauf unter Linux testen. Hier ist die Treiber-Situation noch unübersichtlicher als bei der reinen Bildausgabe.

Valve wird den Linux-Grafikstack weiter verbessern. AMDGPU und Mesa werden besser. VRR und HDR kommen voran. Ob HDMI-2.1-FRL im freien Stack landet, hängt aber nicht primär von Entwicklungskapazitäten ab, sondern davon, ob das HDMI Forum seinen Lizenzrahmen öffnet oder Hersteller eine konforme Open-Source-Implementierung freigeben. Beides ist möglich, aber keines davon hat ein Datum.

Die eigentliche Frage ist: Wie lange hält die Community die Dongle-Lösung für akzeptabel – und ab wann wird der Lizenz-Druck auf das HDMI Forum groß genug, um sich zu bewegen?