Wechhe schrieb:
Am geilsten ist ja, dass HDMI selbst offene Standards (wie VRR) unterstützt - aber selbst Dinge nicht offenlegen will.
? Was soll an HDMI VRR offen sein? "VRR" alleine ist nur der Überbegriff, kein Standard. Es gibt sehr viele Standards. Vesa Adaptive Sync, G-Sync proprietär, FreeSync über HDMI proprietär und auch mit HDMI 2.1 eingeführt HDMI VRR das nicht kompatibel zu FreeSync HDMI ist.
garfield121 schrieb:
aber einzelne Komponenten verschiebt man dann halt in proprietäre Firmware-Dateien.
Firmware und Treiber sind sehr unterschiedliche Teile. Wenn der Job den du machen willst ist: dem Nutzer anbieten, was der Monitor kann, und dann das gewählte mit dem Monitor aufbauen, kannst du das nicht einfach in "Firmware" verstecken. Das würde ja erfordern, dass die GPU völlig autonom, ohne Code auf der CPU selbst eine HDMI Verbindung aufbauen kann, mit was auch immer für Einstellungen sie möchte. Das ist auch nicht unbedingt eine Fähigkeit die direkt in der Hardware vorhanden ist. Und Binary Blobs mag der Linux Kernel gar nicht. Das wird für Firmware, die auf den Peripherien selbst läuft geduldet. Deswegen wird Nvidia ja so bekämpft, weil der Großteil der ihrer Treiber proprietär ist. Gibt genügend Kerneletnwickler die versuchen mit Absicht dem Steine in den Weg zu legen, aus Prinzip.
MGFirewater schrieb:
es wird eher auf usb c 3.2 bzw. thunderbolt hinauslaufen
Das hat selbst keine Displayausgabe. Dafür wird in beiden Fällen dann DisplayPort verwendet.
DevPandi schrieb:
das Protokoll analysieren könnte und darauf aufbauend einen freien Standard aufbauen könnte und damit über kurz oder lang die Lizenzen flöten gehen.
Wieso sollte die Lizenz verloren gehen? Ja, klingt einleuchtend, dass die ihren geheimen Standard weiterhin geheim hallten wollen und eine OpenSource Implementierung von einem Großteil würde dem Leaken einem Großteil der Specs entsprechen. Aber selbst wenn, könnten die immer noch Lizenzgebühren einklagen von jedem der den Opensource-Code nachweislich verwendet. Ist bei x264 und H.264 und anderem Zeug der MPEG ja nicht anders. Also die Lizenzgebühren für verbaute HDMI Stecker / Implementierungen sind nicht direkt in Gefahr. Es würde nur einen Großteil des Standards öffentlich machen. Vllt macht es das wesentlich schwerer von irgendwelchen kleinen Firmen Gebühren einzutreiben, weil man die erst finden und ihnen drohen / klagen muss anstatt dass die schon unterschreiben müssen, bevor sie überhaupt anfangen an HDMI zu entwickeln.
DevPandi schrieb:
Mein LG schaltet sich unter HDMI nicht ab, wie eigentlich eingestellt.
Das ist aber kein Problem von HDMI, das ist ein Problem der Implementierungen von Quelle oder Ziel, höchstwahrscheinlich des Monitors. HDMI macht hier nichts das verhindert.
Evil E-Lex schrieb:
DP hat bei Nutzung von KVM-Switches allerdings den Nachteil, dass es im Gegensatz zu HDMI nicht in der Lage ist, einen angeschlossenen Monitor zu signalisieren, wenn auf einen anderes System umgeschaltet wird. Das hat zur Folge, dass es für die Systeme beim Umschalten jedes Mal so wirkt, als wäre das DP-Kabel im laufenden Betrieb entfernt worden
Nein. HDMI ist von Grund auf wo auch immer sie können simplistisch und dumm gehalten. Während DP vorrausschauend und flexibel ist. Deshalb melden DP Geräte periodisch den Zustand der Verbindung zurück. Damit der Host mitbekommt, wenn die Verbindung abbricht oder Aussetzer hat. Deshalb ist es aufwendiger gegenüber einem PC einen DP Monitor zu faken. Bei HDMI gibt es quasi keine Rückmeldung vom Bildschirm. Nachdem der Host also einmalig eine Verbindung mit dem echten Monitor aufgebaut hast, musst du quasi nur eine einzige Leitung korrekt anschließen um den Host zu belügen. Und fake EDID Daten auszuliefern ist viel einfacher, da das separate Leitungen sind, und nicht "DP Protokoll" zu spechen erfordert. Es gibt auch genauso KVMs mit EDID Emulation über DP. HDMI ist nur so Dumm dass man es einfacher belügen und verbiegen kann.
Das ganze hat auch Nachteile. Weil die KVM dann nicht nur Daten durchleiten muss, sondern verstehen muss, was der Monitor kann um das gegenüber dem PC dann auch passend zu faken.
ghecko schrieb:
AMD wollte das im offenen Teil des Treibers implementieren. Intel, Apple und Nvidia haben das in den Blob verfrachtet, wo es keiner nachvollziehen kann.
Firmware-Blob != Treiber-Blob. Treiber-Blobs mag Linux gar nicht. Deshalb der Krieg mit Nvidia. Und Firmware Blobs erfordert dass das Gerät auf dem die Firmware läuft das auch kann. Und wenn der Punkt in eienr Aushandlung besteht muss das noch nicht mal das Problem läsen.
xexex schrieb:
Intel und Apple nutzen kein HDMI, sondern einen DP->HDMI Baustein.
Intel kann auch nativ HDMI, nur halt die langsamen Versionen mit Stand von HDMI 1.4. Wird spannend, ob und wann wir durch DP-HDMI Converter dann auch die fortgeschrittenen Features wie HDMI VRR sehen. Noch gibt es das ja nicht.