- Um einen günstigen HDMI-Dummy-Stecker, der als 4K-Monitor erkannt wurde, als 1080p-HDMI-Capture-Gerät erscheinen zu lassen, wurde der interne EDID-EEPROM mit einem Raspberry Pi neu beschrieben
- Der Dummy-Stecker lässt den Computer allein durch einen Pull-up am HPD-Pin und ein I2C-EEPROM erkennen, dass ein Monitor angeschlossen ist; die EDID bestimmt dabei Anzeigeinformationen wie unterstützte Auflösung, Audio und Farbraum
- Am HDMI-Port des Raspberry Pi ist ein I2C-Controller für EDID angeschlossen, sodass sich bei korrekter Busnummer je nach Modell die EDID des Dummy-Steckers und eines Capture-Geräts auslesen und vergleichen lässt
- Der praktische Ablauf besteht aus I2C aktivieren,
i2c-tools installieren, Adresse 0x50 prüfen, mit get-edid dumpen und anschließend per i2cset-Schleife 256 Byte schreiben
- Wenn man den falschen I2C-Bus verwendet oder Schreibbefehle auf einen echten Monitor loslässt, kann man die EDID oder andere EEPROMs beschädigen; daher sind Parsen und Zielprüfung vor dem Schreiben Pflicht
Einen 4K-Dummy-Stecker wie ein 1080p-Capture-Gerät aussehen lassen
- Ein günstiger HDMI-Dummy-Stecker, der vor einiger Zeit bei Amazon gekauft wurde, verhielt sich wie ein 4K-Monitor; Ziel war es, ihn so zu ändern, dass er wie ein einfacheres Gerät ohne 4K-Unterstützung erscheint
- Das Ziel ist, die EDID des Dummy-Steckers durch eine EDID-Kopie eines von mehreren 1080p-HDMI-Capture-Geräten zu ersetzen
- Nach dem Austausch erkennt der Computer statt eines 4K-Monitors ein angeschlossenes HDMI-Capture-Gerät
Rolle von HDMI-Dummy-Steckern und EDID
- Dummy-Stecker für HDMI, DVI und ähnliche Standards verarbeiten das Videosignal nicht wirklich, sondern enthalten nur die minimale Schaltung, damit ein Videoausgabegerät wie ein Computer glaubt, dass ein Monitor angeschlossen ist
- Im Allgemeinen werden zwei Dinge benötigt
- Die EDID enthält Informationen wie Hersteller des Monitors, Herstellungsdatum, unterstützte Auflösungen, Audiokanäle und Farbräume
- Solche Dummy-Stecker sind nützlich, um ein Betriebssystem auf einer Headless-Maschine glauben zu lassen, dass ein Monitor angeschlossen ist
Der HDMI-I2C-Bus des Raspberry Pi
- Am HDMI-Port eines Raspberry Pi Zero ist ein I2C-Controller zum Lesen der EDID mit den richtigen Pins verbunden
- Je nach Pi-Modell sind folgende I2C-Busse relevant
- Pi 0-3:
/dev/i2c-2
- Pi 4:
/dev/i2c-20, /dev/i2c-21
- Pi 5:
/dev/i2c-11, /dev/i2c-12
- Bei einem Raspberry Pi Zero wird
edid_i2c=2 gesetzt
- Bei anderen Modellen muss die Busnummer entsprechend der obigen Liste angepasst werden
Vorbereitung
- Auf einer frischen Installation von Raspberry Pi OS Lite wird zunächst die I2C-Umgebung eingerichtet
sudo raspi-config ausführen und unter Interface Options I2C aktivieren- Mit
sudo apt install i2c-tools die I2C-Werkzeuge installieren
- Beim Pi Zero kann der Netzwerkzugang problematisch sein, sodass eventuell ein USB-Ethernet-Adapter nötig ist
- Alternativ kann man die SD-Karte in einen Debian-/Ubuntu-Desktop-PC stecken,
binfmt-support und qemu-user-static installieren und dann per chroot in das rootfs der SD-Karte wechseln, um apt install auszuführen
- Je nach Arbeitsumgebung wird möglicherweise auch ein HDMI-auf-Mini-HDMI-Adapter benötigt
Ursprüngliche EDID lesen und prüfen
- Zuerst wird geprüft, ob der Dummy-Stecker als EDID-EEPROM erkannt wird
edid_i2c=2
i2cdetect -y $edid_i2c
- Im Ergebnis wurde an Adresse
0x50 ein I2C-Gerät erkannt; diese Adresse wird für EDID verwendet
- Dieser Dummy-Stecker antwortete außerdem auf
0x51 bis 0x57; dort scheinen Kopien derselben EDID zu liegen
- Nicht alle Dummy-Stecker verhalten sich so; bei einem anderen Dummy-Stecker wurde nur
0x50 erkannt
- Die ursprüngliche EDID wird mit folgendem Befehl gedumpt
get-edid -b $edid_i2c > edid-orig.bin
get-edid meldete, dass die 256-Byte-EDID auf I2C-Bus 2 erfolgreich gelesen wurde- Derselbe Dump wird zweimal durchgeführt und verglichen, um sicherzustellen, dass die Ergebnisse identisch sind
- Danach wird mit
od ein Hex-Dump ausgegeben und zur Prüfung auf gültige EDID bei edidreader.com eingefügt
od -v -An -txC edid-orig.bin
EDID des Capture-Geräts auf den Dummy-Stecker schreiben
- Nach dem Sichern der ursprünglichen EDID des Dummy-Steckers wird dieser vom HDMI-Port des Pi abgezogen und das HDMI-Capture-Gerät angeschlossen
- Dessen EDID wird auf dieselbe Weise gedumpt
get-edid -b $edid_i2c > edid-capture-card.bin
- Auch die EDID des Capture-Geräts wird auf Gültigkeit geprüft
- Danach wird das Capture-Gerät entfernt, der Dummy-Stecker wieder angeschlossen und die EDID des Capture-Geräts in den EEPROM des Dummy-Steckers geschrieben
edidbytes=($(od -v -An -txC edid-capture-card.bin))
for i in "${!edidbytes[@]}"; do
byte=0x${edidbytes[$i]}
echo Writing byte $i: $byte...
i2cset -f -y $edid_i2c 0x50 $i $byte
done
- Dieses Skript erzeugt aus der Dump-Datei ein Array aus zweistelligen Hex-Strings der EDID, setzt vor jedes Byte
0x und schreibt sie der Reihe nach mit i2cset in den EEPROM
- Es gibt auch Werkzeuge wie edid-checked-writer, aber die oben gezeigte Methode funktioniert bereits mit den standardmäßigen Linux-I2C-Userspace-Tools und bash oder dash
Schreibergebnis prüfen
- Nach dem Schreiben wird die EDID des Dummy-Steckers erneut gelesen und mit der EDID-Datei des Capture-Geräts verglichen
get-edid -b $edid_i2c > edid-test.bin
diff edid-test.bin edid-capture-card.bin
diff gab keine Ausgabe aus, was bestätigt, dass der neue Dump identisch mit der ursprünglichen EDID des Capture-Geräts ist- Der EEPROM des Dummy-Steckers wurde damit mit der EDID des Capture-Geräts neu programmiert
- Beim anschließenden Booten an einem Testcomputer verhielt sich das System so, als wäre statt eines 4K-Monitors ein HDMI-Capture-Gerät angeschlossen
Risiken, die vor dem Schreiben geprüft werden müssen
- Wenn dieses Verfahren ausgeführt wird, während ein echter Monitor angeschlossen ist, und dessen EDID nicht geschützt ist, kann der Monitor beschädigt werden
- Schreibbefehle dürfen nur ausgeführt werden, wenn am HDMI-Port ein Gerät angeschlossen ist, das notfalls kaputtgehen darf, etwa ein Dummy-Stecker
- Man muss sicher sein, den richtigen I2C-Bus zu verwenden, und vor dem Schreiben die EDID lesen und parsen, um zu prüfen, dass dort tatsächlich eine echte EDID vorliegt
- Führt man diese Befehle auf einem PC aus, besteht die Gefahr, versehentlich Nicht-EDID-Hardware wie das SPD-EEPROM eines RAM-Moduls zu flashen
- Die Verwendung eines Raspberry Pi statt direkter I2C-Schreibexperimente auf einem echten PC reduziert das Risiko, den Desktop-PC zu beschädigen
- Dasselbe Verfahren lässt sich umgekehrt auch nutzen, um einen alten 1080p-Dummy-Stecker mit einer 4K-fähigen EDID zu versehen
1 Kommentare
Hacker-News-Kommentare
Kleiner Hinweis für alle, die das zu Hause ausprobieren wollen: Solche günstigen Dummy-Stecker haben nur 256 Byte EEPROM, was nicht ausreicht, um mehrere erweiterte EDID-Blöcke zu speichern, die für hohe Auflösungen und hohe Bildwiederholraten nötig sind.
Wenn man nur 1080p60 braucht, ist das in Ordnung, aber um einen 4k240-Monitor zu emulieren, taugt es nicht.
Außerdem ist bei manchen die Schreibschutzleitung auf high oder low festgelegt, sodass man zum tatsächlichen Beschreiben etwas Hardware-Arbeit leisten muss.
Eine Einschränkung solcher Dummy-Stecker ist, dass sie HDCP nicht unterstützen.
Sie eignen sich gut, um auf einer Headless-Maschine bestimmte Ausgabeauflösungen zu erzwingen, versagen aber, wenn man etwas ausführen muss, das HDCP verlangt.
Ich frage mich, ob es eine gute Lösung gibt, die wie ein HDMI-Dummy-Stecker funktioniert und zusätzlich die HDCP-Aushandlung übernimmt.
Ich muss Video-Streaming-Apps testen, die HDCP für die Wiedergabe in voller Auflösung verlangen, und es ist unpraktisch, für jeden Test jeweils einen Fernseher bereitzustellen.
Die bisherige Lösung, die ich gefunden habe, ist ein HDMI-Multiviewer, der HDCP offenbar pro Port separat aushandelt.
Er kann eine voreingestellte EDID verwenden oder die EDID von einem an HDMI-Ausgang 1 angeschlossenen Gerät einlernen und lässt, solange der Splitter mit Strom versorgt wird, den Ausgang wie einen angeschlossenen Monitor erscheinen, selbst wenn dort nichts verbunden ist.
Soweit ich weiß, handelt er HDCP zwischen Computer oder Konsole und dem Splitter aus und sendet das Signal ohne HDCP an den Ausgangsmonitor weiter.
https://www.amazon.com/dp/B07VP37KMB
Ich habe ein Embedded-System mit HDMI-Ausgabe und möchte den Boot-Bildschirm durch einen anderen HDMI-Stream ersetzen. Ein statisches Bild reicht aus.
Aus verschiedenen Gründen möchte ich das Embedded-System selbst überhaupt nicht verändern, und ich frage mich, wie man das günstig und robust umsetzen kann.
Allerdings gilt hier Käufer aufgepasst.
Wenn man etwas Neueres als HDCP 1.4 braucht, ist das wahrscheinlich nahezu unmöglich.
In dem Zusammenhang frage ich mich, ob es ein brauchbares Archiv mit EDID-Binärdateien oder einen besseren Generator gibt.
Ich habe programmierbare EDID-Emulator-Stecker, mit denen ich meinen Monitor oder andere Monitore klonen kann, aber wenn ich bestimmte Auflösungen oder Funktionen konfigurieren will, gibt es manchmal keinen Weg dafür. Zum Beispiel 8K mit DSC.
https://github.com/bsdhw/EDID kenne ich, aber für aktuelle Monitore ist das recht eingeschränkt.
Mit https://www.analogway.com/products/aw-edid-editor habe ich auch schon selbst etwas gebaut, aber die vielen Detailunterschiede zwischen den Modi oder das Festlegen von Präferenzreihenfolgen korrekt hinzubekommen ist zumindest für mich ziemlich schwierig.
Meine Empfehlungen sind: der bereits erwähnte AW EDID Editor, das nur für Windows verfügbare CRU, 010 Hex Editor mit EDID-Vorlagen, unter Linux das Flatpak von wxEDID und edid-decode aus v4l-utils.
CRU funktioniert, indem es beim Bearbeiten einer vom Monitor ausgelesenen EDID-Datei Deskriptoren wie die Seriennummer entfernt, um Platz für detaillierte Auflösungen zu schaffen. Unter Wine läuft es nicht.
Bei wxEDID erinnere ich mich daran, dass das Distributionspaket wegen WxWidgets abgestürzt ist, und ich weiß nicht, ob man damit neue Abschnitte anlegen kann.
edid-decode kann man auch als textconv-Werkzeug für git diff verwenden, aber beim Kodieren von EDID-Dateien hilft es nicht.
HDMI-EDID hat offenbar CEA-Erweiterungsblöcke, und DP-EDID hat DisplayID-Erweiterungsblöcke.
Mehrseitige EDIDs mit mehr als 256 Byte habe ich nie gemacht, und ich weiß weder, mit welchem EEPROM-Chip man sie emulieren sollte, noch welches Lese-/Schreibprotokoll bzw. welche API dafür nötig ist.
https://www1.kramerav.com/au/product/edid%20designer
Beide sind kostenlos, aber keine Software, die sich frei weiterverbreiten lässt.
Bei Extron muss man möglicherweise in einem Projekt oder einer Organisation arbeiten, die deren Hardware verwendet.
Ich habe eine günstige 5.1-Surround-Soundbar gekauft, die über HDMI sogar Dolby TrueHD unterstützt, aber der Haken ist, dass sie nur mit Geräten mit eARC-Unterstützung, also neueren Fernsehern, richtig funktioniert.
Wenn ich sie an einen PC anschließe, muss ich SPDIF oder AUX verwenden, wodurch die Qualität sinkt.
Statt einen Audio-Extractor oder Splitter zu kaufen, gibt es vielleicht einen Weg, die PC-EDID zu manipulieren, damit die Soundbar denkt, sie werde per eARC erkannt.
Ich arbeite noch daran, aber leider gibt es keine klaren Richtlinien.
Ich habe kürzlich danach gesucht, aber es war nicht klar, welche Geräte welche Funktionen haben oder ob es unter den günstigeren Produkten etwas Brauchbares gibt.
Solche Produkte gibt es auch als Variante mit Pass-through und sie sind nützlich für ältere Systeme, die mit hochauflösenden Monitoren Probleme haben
Ich habe ein AMD-FX8350-System von etwa 2011, dessen integrierte 880G-Northbridge+Video-Chipsatz HDMI-Bild auf 4K-Displays nicht korrekt ausgeben kann
Wenn man so ein Gerät dazwischen anschließt und ihm sagt, es solle ein 1080p-Bild senden, funktioniert es gut, und der Monitor skaliert es per ganzzahligem 2x-Upscaling auf 4K hoch
Meines ist ziemlich hochwertig: Es kann die EDID vom Monitor lesen und speichern und dann als Override für einen anderen Monitor verwenden
Ein weiterer großer Vorteil ist, dass man erzwingen kann, dass der Monitor immer als erkannt gilt
Einer meiner Monitore verhält sich beim Ausschalten so, als wäre er physisch getrennt worden, was diverse Probleme verursacht hat, und das Pass-through hat das vollständig gelöst
Das Produkt, das ich nutze, ist das HD-EWB von THWT
HDMI-Dummy-Plugs sind eine Hardware-Lösung für ein Softwareproblem, das eigentlich gar nicht existieren sollte
Ich frage mich, warum Dummy-Plugs nötig sind
Ich verstehe nicht, was man mit einem Dummy-Plug tun kann, was nicht auch per Software ginge; ich frage aus der Perspektive von jemandem, der 18 virtuelle Displays problemlos ohne Dummy verwendet hat
Der Rechner hat zwei GPUs; die AMD-GPU ist für den Linux-Host, und die NVidia-GPU wird per Passthrough an den Windows-Gast durchgereicht
Looking Glass erfasst die Ausgabe der NVidia-GPU und zeigt sie in einem Fenster auf meinem Desktop an
So kann ich Windows-Software in der VM verwenden, und die Performance ist auch ordentlich. Seit Windows 7 braucht Windows praktisch Grafikbeschleunigung, um vernünftig benutzbar zu sein
Das Problem ist, dass die NVidia-GPU nichts tut, wenn kein Display angeschlossen ist
NVidia-Quadro-GPUs können die Monitor-EDID dumpen und diese Datei einem Ausgang zuordnen, aber Consumer-GPUs unterstützen das nicht
Deshalb braucht man einen Dummy-Plug
Man verwendet den Dummy-Plug-Bildschirm als PowerPoint-Ausgabe und den Laptop-Bildschirm für die Referentennotizen
Danach teilt man einfach den Dummy-Plug-Bildschirm
Für Hacker-News-Leser ist das vielleicht nicht die beste Antwort, aber für Lehrkräfte oder Vertriebsmitarbeiter ist es wirklich simpel
Es kann auch wegen OBS-Streaming oder Setups für Game-Streaming mit Steam oder Parsec nötig sein
Vor ein paar Jahren ging es einigermaßen mit Linux/Xorg und Open-Source-Treibern sowie mit Windows+Nvidia, aber unter MacOS oder Windows+AMD/Intel-GPU funktionierte es nicht besonders gut
Wenn man das Betriebssystem austrickst, damit es glaubt, ein Display sei angeschlossen, führt man eine neue Variable ein, die in der realen Deployment-Umgebung der Nutzer gar nicht existiert; ein Dummy-Plug ist dann eine günstige Hardware-Lösung
Es ist vermutlich kosteneffizienter, einfach einen zu kaufen und einzustecken, als einen Ingenieur
echo on > /sys/whateverund die dazugehörige Logik schreiben zu lassenIch habe für Remote-Game-Streaming per Software einen gefälschten 4K-Monitor auf meinem Desktop hinzugefügt, und es war deutlich komplizierter als erwartet
https://pfy.ch/programming/4k-sunshine.html
Interessanter Tipp: Mit demselben Verfahren kann man auch die in normalen Monitoren oder Laptop-Bildschirmen gespeicherte EDID ändern
Manchmal kann man an eine andere I2C-Adresse schreiben und damit sogar verschiedene Einstellungen des TCON ändern
Ein Raspberry Pi ist dafür nicht zwingend nötig; jeder Computer reicht
Ich modifizierte ihn so, dass die LED-Hintergrundbeleuchtung strobt, um wie bei einer CRT ein Bild ohne Bewegungsunschärfe zu erzeugen
Dabei stellte ich fest, dass der DDC-Bus auch andere Register zur Steuerung der Hintergrundbeleuchtung und Ähnlichem offenlegt, und ich habe für das Strobing eine externe Schaltung angeschlossen
Es gab auch Register zum Lesen und Schreiben des Flash-ROMs, also habe ich einen Dump erstellt, einen 8051-Disassembler geschrieben, grobe Reverse Engineering betrieben und schließlich das ROM so modifiziert, dass es einen Strobe-Modus enthielt
Dieser Modus belegte den unteren Bereich der Helligkeitsregelung, sodass man ihn über das OSD oder die normale DDC-Helligkeitssteuerung aktivieren und anpassen konnte
Zum Flashen musste ich das Gerät öffnen und eine Schreib-Leitung anschließen
Praktischerweise gab es einen vblank-Interrupt, und der Timer zur Steuerung der LED-Hintergrundbeleuchtung hatte einen Modus, in dem man sie direkt vor dem nächsten Interrupt einschalten und nach einer einstellbaren Zeit wieder ausschalten konnte
Das war genau das richtige Timing, um die Hintergrundbeleuchtung direkt nach der stabilen LCD-Aktualisierung einzuschalten
Ursprünglich wollte ich nur ein mehrere Sekunden langes Boot-Logo loswerden, und das hat funktioniert
Wahrscheinlich wird das nur bei Billigprodukten weggelassen
Ohne Schutz ist das riskant, weil ein Spannungs-Glitch beim Lesen in einen Schreibvorgang umschlagen und den Flash beschädigen kann
„Wenn man diesen Befehl auf einem PC ausprobiert, kann man aus Versehen Hardware flashen, die keine EDID ist, zum Beispiel das SPD-EEPROM eines RAM-Moduls“
Normalerweise würde man ein vorprogrammiertes EEPROM kaufen, es auf die Platine setzen und die Write-Enable-Leitung so verdrahten, dass sie niemals high wird
Es ist schon merkwürdig, in einem Produkt wie einem Monitor ein EEPROM zu verbauen und beschreibbar zu lassen, aber ich habe bei ausgelieferter Hardware schon noch Seltsameres gesehen
Ich bin verwirrt
Ich hatte erwartet, den Plug an die GPIO-I2C-Pins anzuschließen, aber es scheint zu reichen, ihn einfach in den RPi zu stecken
Falls das so ist, frage ich mich, ob HDMI direkt eine I2C-Schnittstelle offenlegt
Wie im Artikel erwähnt, hat der RPi einen I2C-Controller, der mit den Pins dieses HDMI-Ports verbunden ist. Denn über DDC muss er die EDID lesen können
Es würde mich interessieren, ob jemand einen günstigen DisplayPort-EDID-Emulator kennt, der Probleme mit KVM und Linux lösen kann
Als ich zuletzt nachgesehen habe, war er deutlich teurer als HDMI, sodass es fast sinnvoller gewesen wäre, gleich ein neues KVM zu kaufen
Stattdessen nutzt es den DisplayPort-eigenen Hochgeschwindigkeits-AUX-Bus, der wesentlich komplizierter zu handhaben ist
Ohne VESA-Mitgliedschaft und die Unterzeichnung einer ganzen Reihe von NDAs wird es wohl schwer, überhaupt an ordentliche Dokumentation zu kommen
https://foosel.net/til/how-to-override-the-edid-data-of-a-mo...
Wenn man allerdings einen virtuellen Monitor hinzufügen möchte, ist unklar, ob https://askubuntu.com/questions/453109/add-fake-display-when... funktioniert
Ich frage mich, ob sich Dummy-Stecker auch dafür nutzen lassen, Geräte-Fingerprinting zu verändern