News Keine Freigabe: AMDs Open-Source-Kampf für HDMI 2.1 unter Linux ist verloren

Ray519 schrieb:
Nein. HDMI ist von Grund auf wo auch immer sie können simplistisch und dumm gehalten. Während DP vorrausschauend und flexibel ist.
Wie, nein? Ich habe geschildert, was ich täglich auf der Arbeit erlebe. Soll ich mich jetzt freuen, dass meine Monitore und KVM-Switches zwar das überlegene Protokoll haben, aber trotzdem schlechter als das dumme HDMI funktionieren?
Als ich die KVM Switches angeschafft habe, stand nichts davon dabei, dass die keine EDID-Emulation unterstützen. Ich habe halt naiverweise angenommen, dass das die Geräte schön können werden, wie jeder andere nicht billigst-KVM der letzten 20 Jahre.
Vom Trauerspiel mit Daisy-Chaining hab ich noch gar nicht angefangen. Wieder so eine Sache, die eigentlich ganz toll ist, in der Praxis aber beständig versagt. DP mag für simpel-Setups taugen, ich nutze das an meinem Gaming-PC ja auch, aber gerade da, wo ich maximale Flexibilität erwarte, hat es mich bislang gnadenlos enttäuscht.
Ergänzung ()

don.redhorse schrieb:
Ist aber eher ein Problem vom OS, schätze mal Sinnlos macht das so.
macOS kann ich nicht beurteilen. Die betreiben wir auf der Arbeit nur mit Apple-Hardware. Für Linux stimmt es. Da bleibt mit dem Nouveau-Treiber das Bild gleich ganz weg. Mit dem nVidia-Treiber geht's meist. Bringt einem aber bei Live-Distros nichts.
 
Evil E-Lex schrieb:
Ich habe geschildert, was ich täglich auf der Arbeit erlebe. Soll ich mich jetzt freuen, dass meine Monitore und KVM-Switches zwar das überlegene Protokoll haben, aber trotzdem schlechter als das dumme HDMI funktionieren?
Du hattest geschrieben "DP hat den Nachteil ... dass es im Gegensatz zu HDMI nicht in der Lage ist,". Und das ist falsch. Deine KVM(s) können das nicht. Es gibt andere KVMs die das genauso können wie deine mit HDMI. DP macht es nur aufwendiger, aber verbietet / erlaubt / ermöglicht da nicht mehr oder nicht weniger als HDMI.

Du könntest vllt. sagen "es gibt mehr KVMs mit HDMI als mit DP die das so machen wie ich das möchte" oder das die im Schnitt günstiger sind. Das wäre nicht falsch.

Edit:
Dafür gibt es mit HDMI mehr Monitore bei denen die GPU nicht mitbekommt wenn man den Monitor ausschaltet, während die Mehrheit der Monitore mit DP das erkennbar macht. Das ist aber genauso wenig die Schuld von HDMI. Nur das die naivste Implementierung von HDMI das eine macht, während die simpelste Implementierung von DP das andere macht. Beides kann jeweils so verbaut werden, dass das Gegenteil erreicht wird.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: buyman, ErbarmeHesse und Iarn
Aten schreibt das dazu:
Wie bei DisplayPort KVM Switches üblich, kann das Umschalten zwischen KVM Ports bei einem erweiterten Desktop dazu führen, dass auf dem erweiterten Desktop geöffnete Fenster auf eine Standardkonfiguration auf dem Hauptbildschirm zurückgesetzt werden. Dies liegt an der Art des DisplayPort Protokolls und erfordert möglicherweise eine manuelle Nachjustierung.
Und bei KVM-Switch.de findet man folgenden Hinweis:
Hinweis im Zusammenspiel mit DP KVM-Switches:
Ein DP KVM-Switch kann, technologisch bedingt, die Monitore nicht als vorhanden vortäuschen.
Das bedeutet, sofern ein weiterer Monitor (z.B. Notebook-Display) aktiv ist, das alle Fenster beim weg-schalten auf den noch aktiven Monitor springen und dort bleiben.
Liest sich für mich, als wäre durchaus das Protokoll schuld. Die EDID-Emulation ist etwas, dass die KVM-Switches selbst implementieren müssen.
 
Nightmar17 schrieb:
Würde es cool finden, wenn man im PC/Monitor Bereich einfach komplett auf Displayport umstellt und fertig.
Aktuelle Grafikkarten haben eh schon meistens mehrere DP-Ports und nur einen einzelnen HDMI-Port. HDMI scheint da eher unter "na gut, für manche Geräte braucht man das vielleicht noch" zu laufen.
 
  • Gefällt mir
Reaktionen: nazgul77 und Gelbsucht
Ja, das was die schreiben liest sich tatsächlich so wie du das sagst. Das ist schlicht falsch. Wie gesagt, der Grund ist, dass es bei DP eine Hin-und Zurück-Kommunikation gibt. Deshalb müsste eine Emulation von einem Fake-Monitor auch diese regelmäßige Kommunikation mit dem Monitor faken, weil die GPU sonst davon ausgeht dass der Monitor weg ist oder nicht mehr funktioniert und entsprechend reagiert. DP kann hier wesentlich mehr als HDMI. Bei HDMI kann eine GPU noch nicht mal herausfinden ob der Monitor an oder aus ist, solange der Monitor nicht so tut als würde das Kabel ausgesteckt werden wenn er aus ist. Deshalb ist es super billig einen HDMI Monitor zu faken. Heißt nicht dass es mit DP nicht möglich ist.

Und tatsächlich könnte es bei HDMI sogar noch eine Zwischenstufe geben: ohne EDID-Emulation würde die GPU den Monitor zwar nicht korrekt erkennen, wenn sie frisch angeht und der Monitor nicht angeschlossen ist. Aber einmal erkannt, braucht es nur eine Leitung um nicht mitbekommen das der Monitor weg ist.
Bei DP wird das beides über den Aux-Link gemacht, der alles mögliche überträgt. Einen aktiven Monitor zu faken ist hier aufwendiger als die EDID-Emulation (die ja eigentlich nur das Kopieren von 256 Byte ist). Das Protokoll ist schuld was wesentlich schwerer und was einfacher ist. Aber nicht daran dass es bei dir nicht geht.
Und sie machen es nicht schwer um dich zu ärgern. Beide haben KVMs nicht vorgesehen. DP macht das um eine stabilere Übertragung zu gewährleisten.
 
Zuletzt bearbeitet:
Naja, für PC Gaming unter Linux jetzt nicht allzu tragisch, da DisplayPort doch sowieso dominierend ist, oder?

Warum man sich dem wachsenden Linux Gaming so verschließt macht für mich wenig Sinn, aber gesunde Konkurrenz ist ja am Start und wird verdient profitieren.
 
Evil E-Lex schrieb:
Liest sich für mich, als wäre durchaus das Protokoll schuld. Die EDID-Emulation ist etwas, dass die KVM-Switches selbst implementieren müssen.
Es gibt sowohl für HDMI als auch für DP Edid-Inserter. Es kann aber sein, dass die für HDMI primitiver sind. Die kann man sich mit ein paar Widerständen, einem Kondensator und einem I2C-EEPROM selbst bauen (und dann z. B. in ein HDMI-Kabel einbauen):
Screenshot_20240301-201736_Gallery.png

Dass das mit HDMI so einfach und billig ist, ist noch ein Grund, warum ich HDMI mag.
 
  • Gefällt mir
Reaktionen: Ray519
Ray519 schrieb:
Intel kann auch nativ HDMI, nur halt die langsamen Versionen mit Stand von HDMI 1.4.
Das ist richtig, aber da gibt es das Problem ja auch nicht. Die aktuellen Lösungen bei Intel basieren jedenfalls auf einer Umsetzung von DP2.0 auf HDMI2.1.
This DP-HDMI2.1 PCON is protocol converter support as part of the VESA DisplayPort 2.0 specification for interfacing with HDMI 2.1 displays. This protocol converter support for DisplayPort to HDMI 2.1 is necessary even for use with converter chips like the Realtek RTD2173. With these tentative Linux kernel patches, the Intel graphics driver developers working on this code were able to drive an HDMI 2.1 panel via the RTD2173 chip with a Tigerlake laptop over DisplayPort.
https://www.phoronix.com/news/DP-HDMI2.1-PCON-Intel-Linux
Damit ist man bei Intel von den Lizenzbeschränkungen nicht betroffen, hat aber natürlich prinzipiell andere Probleme. Technisch müsste Intel aber die gleichen Probleme mit den Meteor Lake CPUs haben, außer sie haben das irgendwie anders gelöst.
https://www.phoronix.com/news/Intel-HDMI-2.1-FRL-Linux
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Ray519
Toprallog schrieb:
Gibt es einen Grund warum keine Freigabe erteilt wird?
Vermutung meinerseits: HDMI ist selbst kein quelloffener Standard, es werden ja Lizenzgebühren (Hersteller) fällig bei jedem Gerät. Und die HDMI Leute wollen , daß dies so bleibt. Es geht also ums Geld, wieder mal.
 
xexex schrieb:
Technisch müsste Intel aber die gleichen Probleme mit den Meteor Lake CPUs haben.
Ja. Ab da haben sie FRL und auch HDMI VRR Support nativ drin, wenn auch nur bis FRL 4. Um es genauer zu wissen, müssten wir wissen, was genau das HDMI Forum nicht in Opensource haben will. Gut möglich dass es nur manche Ecken trifft, wo man besonders viel aus dem Quellcode lesen könnte, die aber auch einfach in Firmware / Hardware verschoben werden könnten. Oder wo es nur auf Kosten bestimmter Features geht.

Die News selbst hat HDMI 2.1 ja eher als ganzes betrachtet, was vllt nicht notwendig ist. Auch müssten Entwickler die den HDMI 2.1 Standard nie gesehen haben das trotzdem reverse engineeren können. Und für manche Ecken wird das mit Sicherheit gehen. Aber natürlich nichts wo AMD einfach seinen existierenden Code opensourcen kann / wesentlich aufwendiger.
 
"HDMI-Forum lehnt den Code von AMD ab"

Wenn es NICHT proprietär ist, kann es halt nix. So weit sind wir schon ... :stock:
 
Ray519 schrieb:
Gut möglich dass es nur manche Ecken trifft, wo man besonders viel aus dem Quellcode lesen könnte, die aber auch einfach in Firmware / Hardware verschoben werden könnten. Oder wo es nur auf Kosten bestimmter Features geht.
Phoronix mutmaßt es könnte die gleiche Problematik wie bereits früher sein und die Mediendekodierung in Verbindung mit HDCP betreffen.
https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
 
Kann denn Linux überhaupt HDCP? Hätte ich jetzt gar nicht erwartet. Gibt es irgendeine Anwendung die überhaupt End-to-End Kopierschutz auf Linux nutzt. Mein letzter Stand war Dinge wie Netflix bieten da eh nur das an, was sie auf Windows auch ganz ohne Kopierschutz oder nur mit längst geknackten anbieten und alles weitere geht eh nicht. UHDs gehen eh nicht, weil die Intel SGX vorschreiben.

Kopierschutz und ein offenes System wo der Nutzer die volle Kontrolle hat ist einfach nicht miteinander vereinbar. Opensource ist gar nicht das Problem. Aber der Nutzer darf keine Rechte haben um in den laufenden Prozess einzugreifen, weil dann wäre der Schutz ja wertlos und du könntest die Keys nicht geheimhalten.
 
Shy Bell schrieb:
Also ich habe einen LG Oled C2 am Linux-PC hängen und bin der Meinung, dass ich über 60 Hz nutzen kann.
Diesen Artikel verstehe ich so, dass es nicht der Fall sein soll. Kann mir das jemand erklären, warum ich ein flüssigeres Bild sehe? Sowohl PC als auch Fernseher berichten eine höhere Bildrate z.B. 100.
Ja das geht, allerdings mit Chroma Subsampling 4:2:0 anstatt 4:4:4.
 
Kann mir mal kurz jemand erläutern wo die Vorteile von HDMI liegen? Besonders beim Ton. Weil in der Bildwiedergabe ist DP 2.1 doch ziemlich vorne. Wieso baut kein TV Herstelller Displayport ein? Oder liegt das eher bei den AV Receivern die dann nicht mehr kompatibel wären. Auch wegem HDMI ARC etc. Kenne mich damit null aus.
 
rulaman schrieb:
Kann mir mal kurz jemand erläutern wo die Vorteile von HDMI liegen? Besonders beim Ton. Weil in der Bildwiedergabe ist DP 2.1 doch ziemlich vorne. Wieso baut kein TV Herstelller Displayport ein? Oder liegt das eher bei den AV Receivern die dann nicht mehr kompatibel wären. Auch wegem HDMI ARC etc. Kenne mich damit null aus.
Vermutlich ein Mix von HDMI deckte als ersted die Anforderungen ab und heute wohl einfach aus Gewohnheit weil das Öko-System eben da ist mit AV-Receivern, Spielkonsolen etc.
DisplayPort könnte man zwar zusätzlich noch einbauen, auch wenn die Lizenz vielleicht nichts kostet, ist es trotzdem Aufwand das zusätzlich zu unterstützen.
 
@Frank
"Seit Oktober 2023 hatte AMD nach Aussagen des Entwicklern nun auf eine Antwort der Gruppe gewartet, nun kam die – für AMD und Linux-Nutzer – negative Entscheidung des HDMI Forums."
Da stimmt was nicht ;D
 
  • Gefällt mir
Reaktionen: Frank
Ray519 schrieb:
Kann denn Linux überhaupt HDCP?
Gehe ich mal stark von aus, es sei denn auf den meisten Receivern, DVD- oder BR-Playern läuft als OS ein embedded Windows oder eine Eigenentwicklung.
 
Zurück
Oben