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

[Sunjy Kamikaze]

USB-C bitte für alles. Am besten noch rund und Magnetisch das ich das Kabel nur noch hinter den 98Zoll TV Werfen muss und es automatisch dort landet wo es hin gehört.

 

[riloka]

Wir haben doch schon einen USB-C Stecker der um 180° gedreht werden kann und dennoch passt.
Wenn wir jetzt wieder die Form ändern, müssen wir wieder mit Adaptern anfangen und haben einen enormen Rückschritt im Prozess und wenig Unterschied zum jetzigen Problem mit verschiedenen Steckern.
Magnetisch könnte man vermutlich eher rückwärtskompatibel als Funktion hinzufügen.

 

[Sunjy Kamikaze]

Ja das wäre Feintunning. Finde USB -C in der Form schon genial. Ein kabel/Stecker für alles und fertig.

 

[mibbio]

AndroidTV und WebOS zu großen Teilen vermutlich.

Was im Endeffekt aber auch nur Linux-Derivate sind, also Linux-Kernel mit proprietären Komponenten des Herstellers. Da ist HDMI 2.1 dann auch kein Problem, weil die Hersteller das einfach als Closed Source Treiber einbauen.

 

[Djura]

Hitachi, Matsushita, Philips, Silicon Image, Sony, Thomson und Toshiba

Schade, dass du AMD nicht aufgeführt hast.

Eine Sauerei, aber von den geldgeilen und misgünstigen Säcken im HDMI-Forum nicht anders erwartbar. Die Entscheidung ist ganz klar profitbedingt gefallen.

Also ist AMD auch geldgeil und missgünstig?
@mibbio hat es richtig gestellt. thx.

 

[mibbio]

Schade, dass du AMD nicht aufgeführt hast.

Es ging in den Beitrag darum, wer das Konsortium gegründet, also HDMI ins Leben gerufen hat. AMD und praktisch Alle, die HDMI nutzen, sind dagegen nur ein einfaches Mitglied. Die sind nicht zwangsweise an der Entwicklung des Standards beteiligt oder verdienen daran. Sogar im Gegenteil, denn man muss zahlendes Mitglied sein und dem Konsortium jährlich mehrere Tausend Dollar Mitgliedsbeitrag überweisen, um die Spezifikationen einsehen zu können und den Standard und Stecker nutzen zu dürfen.

 

[LikeAnIrish]

Ich verstehe eh nicht warum HDMI der Standard ist. Nutze schon immer lieber dp. Da gibt es die Neuerungen gefühlt schon immer eine Ewigkeit vor HDMI ...

 

[riloka]

Es ist ja auch nicht DER Standard sondern einer von mehreren.

 

[Lora]

Also meine Rechner sind über DP mit dem Monitor verbunden, da läuft alles Tip Top 😉
TV etc läuft alles über HDMI/HDMI 2.1. Meinen Rechner gab es ab Werk nur mit
DP Ausgängen. Habe dann zwar die Grakas nachgerüstet, aber bin bei DP geblieben.

 

[Donnerkind]

Ich hab mich so manches Mal geärgert, dass mein Eizo mit 2560×1440 kein HDMI hat, weil ich dadurch auf Mainboards mit DP eingeschränkt bin. Auch jetzt beißt mich das wieder bei der Suche nach einem sinnvollen AM5-ITX-Board. Dafür steht es jetzt sehr gut um die Verbreitung von DP in meinem Haushaut.

Ich hatte mich auch schon darauf gefreut, irgendwann einmal meinen 4K-Fernseher mit 4K@120 zu befeuern. Das wird dann wohl auch nix. Aber wenigstens brauch ich mich jetzt nicht mehr zu ärgern, dass das 10-Meter-HDMI-Kabel, das ich dafür gekauft hab, 4K120 nicht beherrscht, weil ich zu geizig dafür war.😅

Ein Open Source Treiber, der die Spezifikationen implementiert, würde diese logischerweise für Jeden einsehbar machen, ohne dass er für die Einsicht bezahlt.

Man könnte es ja in Assembler implementieren … 😇

 

[mibbio]

Man könnte es ja in Assembler implementieren

Und was würde das bringen? Assembler ist auch keine Geheimsprache, sondern mit den entsprechenden Kenntnissen wie jede andere Programmiersprache lesbar. Entsprechend kann man auch bei Assembler-Code die implementierten HDMI-Spezifikationen rauslesen, sofern es Open Source ist. Egal welche Programmiersprache, das HDMI Forum will schlicht nicht, dass Jemand ohne kostenpflichtige Mitgliedschaft die Spezifikation oder Teile davon einsehen kann - also ist Open Source bei der Umsetzung untersagt.

 

[Ray519]

Und was würde das bringen? Assembler ist auch keine Geheimsprache, sondern mit den entsprechenden Kenntnissen wie jede andere Programmiersprache lesbar.

Wenn Nvidia es in ihrem Binary-Blob Treiber ausliefern kann, dann würde Assembler dem genüge tun. Denn es ist 1:1 übersetzbar (solange man nicht den Standard in Symbolinformationen ausdrückt, was Assembler ja weder ausschließt noch garantiert, genau wie ein Binary).

Aber auch gut möglich, dass diese Aussage, das Nvidia das kann, weil im Binary-Teil vom Treiber geraten und falsch ist und sie einfach gewisse Dinge in Firmware / Hardware auf ihrer GPU machen, die AMD im Treiber machen will.
Und die Firmware kann (und wird vermutlich auch) verschlüsselt sein etc. so dass man den Code nicht einfach sehen kann.

 

[mibbio]

Wenn Nvidia es in ihrem Binary-Blob Treiber ausliefern kann, dann würde Assembler dem genüge tun. Denn es ist 1:1 übersetzbar (solange man nicht den Standard in Symbolinformationen ausdrückt, was Assembler ja weder ausschließt noch garantiert, genau wie ein Binary).

Irgendwie kann ich deiner Logik nicht so ganz folgen. Nochmal, Assembler ist eine ganz normale Programmiersprache, die jeder lesen und verstehen kann - ganz egal, ob da eine Variable jetzt HdmiParamaterX heißt oder einfach nur "a".

Verwechselst du Assembler eventuell mit Maschinencode, also das, was nach dem Kompilieren des Quellcodes im Binary steckt. Man kann beim Quellcode, ob jetzt Assembler, C oder C++, gibt es auch keine Symbolinformationen, die man irgendwie weglassen könnte. Die Symbolinformationen werden vom Compilter optional erstellt, wenn man den Quellcode in Maschinencode/ein Binary übersetzen lässt, damit man das Binary leichter debuggen kann.

 

[Ray519]

Verwechselst du Assembler eventuell mit Maschinencode,

Nein tue ich nicht. Da Assembler 1:1 an Maschinencode klebt, kannst du jeden Maschinencode auch genauso zurück zu Assembler(-Instruktionen) übersetzen (zumindest für alle Architekturen die ich mir angesehen habe und so ziemlich nach Definition). Deshalb ist es entweder: Assembler ist Low-level, weit weg genug von der eigentlichen Spec und es sollte erlaubt sein, oder auch ein unverschlüsseltes Binary darf nicht erlaubt sein, weil es eine Trivialität ist, dass zurück zu Assembler zu übersetzen.

Kommentare kriegst du nicht zurück, aber die braucht man auch nicht reinschreiben / ist ja eine Frage was man da schreibt.

Und Symbolinformationen können auch in einem Binary drin sein oder genauso gut aus Assembler gestrippt werden, wie aus dem Binary.

asmLabel:  <- Symbol Information. Ja im Fließtext drin.
   insn
   insn
   insn
 
1:  <- obfuscated Symbol Information
   ; und was du aus einem Binary in jedem Fall dissassembliert bekommst. Zur Not die Addresse
   insn
   insn
   insn

 

[AlphaKaninchen]

also ist Open Source bei der Umsetzung untersagt.

Auch ein Binärie kann man decompilieren zu Assembler ist das Quasi nur ein Replace...

 

[CountSero]

@mibbio Danke, genau darauf wollte ich hinaus.


Alle die Gründungsmitglieder waren\sind Produzieren International Unterhaltungselektronik und Produzieren\Publishen neben her noch Unterhaltung (Spiele, Filme usw.). Wobei Sony hier wohl am meisten noch mit drin steckt neben Phillips. (Meine Vermutung)

Fast die gleichen Unternehmen waren auch an der Entwicklung der DVD\BluRay beteiligt.

Da die großen Filmfirmen schon immer mit Piraterie zu kämpfen hatten\haben werde diese natürlich auch nicht so schnell davon ablassen HDMI zu verwenden.

Jetzt muss man noch berücksichtigen das sich der Markt durch das Streaming ja immer mehr geändert hat. Das heißt ein wirksamen Kopierschutz für für die Unternehmen immer wichtiger.

Es mag auch sein das der Standard bereits geknackt wurde aber dennoch reicht die Hürde für 90% der Konsumenten noch aus.

Das AMD hier versucht hat gegen diese Riesen anzugehen ist löblich aber es war bereits im Vorhinein ein Kampf gegen Windmühlen.

Somit bleibt hier am ende nur noch der DisplayPort.

 

[Vindoriel]

Alles in allem konnte sich HDMI wohl hauptsächlich dadurch im TV/HiFi-Bereich etablieren weil es eben von den Herstellern gepusht wurde und vor allem schon Ende 2003 startete, DisplayPort hingegen erst 2008, also gut 5 Jahre später, als eben Geräte wie Blu-Ray Player und PS3 sowie Xbox 360 schon längst mit HDMI auf dem Markt waren.

Du vergisst allerdings DVI, welches vor HDMI kam und HDMI basierte sogar auf den Signalen, die man über DVI-D hatte.

 

[UrlaubMitStalin]

Und Symbolinformationen können auch in einem Binary drin sein oder genauso gut aus Assembler gestrippt werden, wie aus dem Binary.

Mann kann sogar Java-Dateien aus dem Java-Code deassemblieren.
Nur ist die Lesbarkeit hier nicht besonders hoch

 

[riloka]

@mibbio

Fast die gleichen Unternehmen waren auch an der Entwicklung der DVD\BluRay beteiligt.

Da die großen Filmfirmen schon immer mit Piraterie zu kämpfen hatten\haben werde diese natürlich auch nicht so schnell davon ablassen HDMI zu verwenden.

Da Displayport hier aber sowohl einen eigenen Kopierschutz bietet als auch HDCP genauso unterstützt ist der Kopierschutz kein Kriterium um bei HDMI zu bleiben.
Da Bluray-Kopierschutz , Widevine und der DVD Kopierschutz CSS erfolgreich ausgehebelt sind, braucht man HDCP und DPCP auch nicht aushebeln, man läd die Materialien direkt an der Quelle, entfernt den Kopierschutz dort und hat perfekte Qualität ohne nochmal Kodieren zu müssen was man am Bildschirm abgefangen hat.

 

[Ray519]

Mann kann sogar Java-Dateien aus dem Java-Code deassemblieren.

Natürlich kein ganz fairer Vergleich, weil du zurück zur Hochsprache willst. Java Bytecode zu Classfiles ist extrem eins zu eins.

Jvm Classfiles enthalten zwangsweise so viel mehr Symbolinformationen als klassische Binaries. Daraus kann man um Welten mehr lesen als aus nativem Code. Auch ist der Bytecode darin quasi nicht optimiert.
Und die einzelnen Methoden sind noch nicht mal miteinander gelinkt, das passiert alles erst beim Ausführen.

Kann man natürlich auch obfuscaten, aber man sieht viel mehr Codestruktur in Bytecode als in Maschinencode, wenn man nicht absichtlich mit O0 kompiliert.