- Pour faire passer un bouchon HDMI factice bon marché, détecté comme un moniteur 4K, pour un périphérique de capture HDMI 1080p, son EEPROM EDID interne a été réécrite avec un Raspberry Pi
- Un bouchon factice fait croire à l’ordinateur qu’un moniteur est connecté uniquement grâce à un pull-up sur la broche HPD et à une EEPROM I2C ; l’EDID détermine les informations de l’afficheur comme les résolutions prises en charge, l’audio et les espaces colorimétriques
- Le port HDMI du Raspberry Pi dispose d’un contrôleur I2C connecté pour l’EDID ; en choisissant le bon numéro de bus selon le modèle, on peut lire et comparer l’EDID du bouchon factice et celle du périphérique de capture
- La procédure consiste à activer l’I2C, installer
i2c-tools, vérifier l’adresse 0x50, dumper avec get-edid, puis effectuer une écriture de 256 octets via une boucle i2cset
- Exécuter une commande d’écriture sur le mauvais bus I2C ou sur un vrai moniteur peut endommager l’EDID ou une autre EEPROM ; il est donc indispensable de parser les données et de vérifier la cible avant toute écriture
Faire passer un bouchon factice 4K pour un périphérique de capture 1080p
- Il s’agit de modifier un bouchon HDMI factice bon marché acheté auparavant sur Amazon, qui se comporte comme un moniteur 4K, afin qu’il apparaisse comme un appareil plus simple ne prenant pas en charge la résolution 4K
- L’objectif est de remplacer l’EDID du bouchon factice par une copie de l’EDID de l’un de plusieurs périphériques de capture HDMI 1080p
- Une fois le remplacement effectué, l’ordinateur reconnaît un périphérique de capture HDMI connecté au lieu d’un moniteur 4K
Rôle des bouchons HDMI factices et de l’EDID
- Les bouchons factices HDMI, DVI, etc. ne traitent pas réellement le signal vidéo ; ils ne comportent que le circuit minimal permettant à une source vidéo, comme un ordinateur, de conclure qu’un moniteur est connecté
- En général, deux éléments sont nécessaires
- L’EDID contient des informations comme le fabricant du moniteur, sa date de fabrication, les résolutions prises en charge, les canaux audio et les espaces colorimétriques
- Ce type de bouchon factice est utile sur les machines headless pour que le système d’exploitation pense qu’un moniteur est connecté
Bus I2C HDMI du Raspberry Pi
- Sur le port HDMI du Raspberry Pi Zero, un contrôleur I2C destiné à lire l’EDID est connecté aux bonnes broches
- Les bus I2C à vérifier selon le modèle de Pi sont les suivants
- Pi 0-3 :
/dev/i2c-2
- Pi 4 :
/dev/i2c-20, /dev/i2c-21
- Pi 5 :
/dev/i2c-11, /dev/i2c-12
- Avec un Raspberry Pi Zero, on utilise
edid_i2c=2
- Sur les autres modèles, il faut adapter le numéro de bus selon la liste ci-dessus
Préparation
- Sur une nouvelle installation de Raspberry Pi OS Lite, il faut d’abord préparer l’accès I2C
- Exécuter
sudo raspi-config, puis activer I2C dans Interface Options
- Installer les outils I2C avec
sudo apt install i2c-tools
- Sur un Pi Zero, l’accès réseau peut poser problème ; un adaptateur USB-Ethernet peut être nécessaire
- Une autre option consiste à insérer la carte SD dans un PC de bureau sous Debian/Ubuntu, à installer
binfmt-support et qemu-user-static, puis à faire un chroot dans le rootfs de la carte SD pour exécuter apt install
- Selon l’environnement de travail, un adaptateur HDMI vers Mini-HDMI peut aussi être nécessaire
Lecture et validation de l’EDID d’origine
- Il faut d’abord vérifier que le bouchon factice est détecté comme une EEPROM EDID
edid_i2c=2
i2cdetect -y $edid_i2c
- Dans le résultat, un périphérique I2C a été détecté à l’adresse
0x50, qui est l’adresse utilisée pour l’EDID
- Ce bouchon factice répondait aussi de
0x51 à 0x57, adresses qui semblent contenir des copies de la même EDID
- Tous les bouchons factices ne se comportent pas ainsi ; un autre bouchon factice n’était détecté qu’en
0x50
- L’EDID d’origine se dumpe avec la commande suivante
get-edid -b $edid_i2c > edid-orig.bin
get-edid indique avoir lu avec succès une EDID de 256 octets sur le bus I2C 2- Il faut effectuer deux fois le même dump et comparer les résultats pour vérifier qu’ils sont identiques
- Ensuite, afficher un dump hexadécimal avec
od, puis le coller dans edidreader.com pour vérifier qu’il s’agit d’une EDID valide
od -v -An -txC edid-orig.bin
Écrire l’EDID du périphérique de capture sur le bouchon factice
- Après avoir sauvegardé l’EDID d’origine du bouchon factice, retirer le bouchon du port HDMI du Pi et brancher le périphérique de capture HDMI
- Dumper l’EDID du périphérique de capture de la même manière
get-edid -b $edid_i2c > edid-capture-card.bin
- Vérifier également que l’EDID du périphérique de capture est valide
- Ensuite, retirer le périphérique de capture, reconnecter le bouchon factice et écrire l’EDID du périphérique de capture dans l’EEPROM du bouchon
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
- Ce script transforme l’EDID du fichier dump en tableau de chaînes hexadécimales à deux caractères, préfixe chaque octet par
0x, puis les écrit dans l’ordre dans l’EEPROM avec i2cset
- Il existe aussi des outils comme edid-checked-writer, mais cette méthode fonctionne avec les outils I2C userspace Linux standard et bash ou dash
Vérification du résultat de l’écriture
- Après l’écriture, relire l’EDID du bouchon factice et la comparer au fichier EDID du périphérique de capture
get-edid -b $edid_i2c > edid-test.bin
diff edid-test.bin edid-capture-card.bin
diff ne produisant aucune sortie, cela confirme que le nouveau dump est identique à l’EDID d’origine du périphérique de capture- L’EEPROM du bouchon factice a été reprogrammée avec l’EDID du périphérique de capture
- Après l’avoir branché sur un ordinateur de test et démarré celui-ci, l’ordinateur se comporte comme si un périphérique de capture HDMI était connecté au lieu d’un moniteur 4K
Risques à vérifier avant l’écriture
- Si cette procédure est exécutée alors qu’un vrai moniteur est connecté et que l’EDID de ce moniteur n’est pas protégée, elle peut endommager le moniteur
- Il faut impérativement n’exécuter les commandes d’écriture que lorsqu’un appareil dont la panne est acceptable, comme un bouchon factice, est connecté au port HDMI
- Il faut être certain d’utiliser le bon bus I2C, et lire puis parser l’EDID avant l’écriture pour confirmer qu’il s’agit bien d’une EDID réelle
- Si ces commandes sont exécutées sur un PC, il est possible de flasher par erreur du matériel qui n’est pas une EDID, comme l’EEPROM SPD d’un module RAM
- Utiliser un Raspberry Pi plutôt que de tester l’écriture I2C sur un vrai PC réduit le risque d’endommager un ordinateur de bureau
- La même méthode peut aussi être utilisée en sens inverse pour placer une EDID compatible 4K dans un ancien bouchon factice 1080p
1 commentaires
Avis sur Hacker News
Petite mise en garde pour ceux qui voudraient essayer chez eux : ces dongles factices bon marché n’ont qu’une EEPROM de 256 octets, ce qui ne suffit pas à stocker les multiples blocs d’extension EDID nécessaires aux hautes résolutions et aux taux de rafraîchissement élevés
Si vous n’avez besoin que de 1080p60, ça va, mais ce n’est pas utilisable pour simuler un moniteur 4k240
De plus, sur certains modèles, la ligne de protection en écriture est fixée à high ou low, donc il faut un peu de bricolage matériel pour pouvoir réellement écrire dessus
Une limite de ces dongles factices est qu’ils ne prennent pas en charge HDCP
Ils conviennent bien pour forcer une certaine résolution de sortie sur une machine headless, mais échouent s’il faut lancer quelque chose qui exige HDCP
Je me demande s’il existe une bonne solution qui se comporte comme un dongle HDMI factice tout en assurant aussi la négociation HDCP
Je dois tester des applications de streaming vidéo qui nécessitent HDCP pour lire en pleine résolution, et avoir une TV dédiée pour chaque test n’est pas pratique
La solution que j’ai trouvée jusqu’ici est un multiviewer HDMI, qui semble négocier HDCP séparément pour chaque port
Il permet d’utiliser un EDID prédéfini ou d’apprendre l’EDID depuis l’appareil connecté à la sortie HDMI 1, puis, tant que le répartiteur est alimenté, il se présente comme un moniteur connecté même si rien n’est branché en sortie
D’après ce que je comprends, il négocie HDCP entre l’ordinateur ou la console et le répartiteur, puis envoie le signal vers le moniteur de sortie sans HDCP
https://www.amazon.com/dp/B07VP37KMB
J’ai un système embarqué qui sort en HDMI, et je voudrais remplacer l’écran de démarrage par un autre flux HDMI. Une image statique suffirait
Pour diverses raisons, je ne veux absolument pas modifier le système embarqué lui-même, et je me demande comment faire ça de manière peu coûteuse et robuste
Mais acheteur, attention
Si vous avez besoin de quelque chose de plus récent que HDCP 1.4, c’est probablement presque impossible
À ce sujet, je me demande s’il existe une bonne archive de binaires EDID ou un meilleur générateur
J’ai un dongle émulateur EDID programmable qui peut cloner mon moniteur ou d’autres moniteurs, mais il arrive qu’il n’y ait pas de moyen de définir une résolution ou une fonctionnalité précise, par exemple du 8K avec DSC
Je connais https://github.com/bsdhw/EDID, mais il est assez limité pour les moniteurs récents
J’ai aussi déjà essayé d’en créer moi-même avec https://www.analogway.com/products/aw-edid-editor, mais régler correctement les différences de détail entre les modes et l’ordre de préférence, entre autres, est assez difficile, en tout cas pour moi
Mes recommandations : AW EDID Editor déjà mentionné, CRU sous Windows uniquement, 010 Hex Editor avec des templates EDID, wxEDID via Flatpak sous Linux, et edid-decode de v4l-utils
CRU fonctionne en modifiant un fichier EDID dumpé depuis le moniteur et en supprimant des descripteurs comme le numéro de série pour faire de la place aux résolutions détaillées. Il ne fonctionne pas sous Wine
Pour wxEDID, il me semble que le paquet de ma distribution plantait dans WxWidgets, et je ne sais pas s’il permet de créer de nouvelles sections
edid-decode peut aussi servir d’outil textconv pour git diff, mais il n’aide pas à encoder les fichiers EDID
D’après ce que j’ai vu, les EDID HDMI ont un bloc d’extension CEA, tandis que les EDID DP ont un bloc d’extension DisplayID
Je n’ai jamais fait d’EDID multipage de plus de 256 octets, et je ne sais pas non plus avec quelle puce EEPROM les émuler, ni quel protocole/API utiliser pour lire et écrire
https://www1.kramerav.com/au/product/edid%20designer
Les deux sont gratuits, mais ce ne sont pas des logiciels librement redistribuables
Pour celui d’Extron, il faut peut-être travailler sur un projet ou dans une organisation qui utilise leur matériel
J’ai acheté une barre de son surround 5.1 bon marché prenant en charge jusqu’au Dolby TrueHD via HDMI, mais le piège est qu’elle ne fonctionne vraiment bien qu’avec des appareils compatibles eARC, donc des TV récentes
Si on la branche à un PC, il faut utiliser SPDIF ou AUX, ce qui dégrade la qualité
Plutôt que d’acheter un extracteur audio ou un répartiteur, il existe une façon de tromper l’EDID du PC pour que la barre de son soit reconnue comme eARC
C’est encore en cours, et malheureusement il n’y a pas de guide clair
J’ai regardé récemment, mais il n’était pas clair quel appareil offrait quelles fonctionnalités, ni s’il existait de bons modèles moins chers
Ce type de produit existe aussi avec passthrough, et c’est utile pour de vieux systèmes qui posent problème avec les moniteurs haute résolution
J’ai un système AMD FX8350 datant d’environ 2011, dont le chipset northbridge+vidéo intégré 880G n’arrive pas à sortir correctement de la vidéo HDMI vers un écran 4K
Si je branche ce genre d’appareil entre les deux pour lui indiquer d’envoyer une image 1080p, ça fonctionne bien, et le moniteur fait un upscaling entier x2 en 4K
Ceux que j’ai sont plutôt haut de gamme : ils peuvent lire l’EDID du moniteur et l’enregistrer, puis l’utiliser comme override pour un autre moniteur
Autre point excellent : ils peuvent forcer la détection permanente du moniteur
L’un de mes moniteurs se comporte quasiment comme s’il était débranché quand on l’éteint, ce qui causait divers problèmes, et le passthrough les a entièrement résolus
Le produit que j’utilise est le HD-EWB de THWT
Les dummy plugs HDMI sont une solution matérielle à un problème logiciel qui ne devrait pas exister au départ
Je me demande pourquoi les dummy plugs sont nécessaires
Je ne vois pas ce qu’on peut faire uniquement avec un dummy plug et pas en logiciel. Je pose la question en ayant utilisé 18 écrans virtuels sans dummy et sans problème
L’ordinateur a deux GPU : le GPU AMD sert à l’hôte Linux, et le GPU NVidia est passé en passthrough à l’invité Windows
Looking Glass capture la sortie du GPU NVidia et l’affiche dans une fenêtre sur mon bureau
Avec cette approche, je peux utiliser des logiciels Windows dans la VM avec des performances correctes. Depuis Windows 7, Windows a pratiquement besoin de l’accélération graphique pour être utilisable
Le problème, c’est que le GPU NVidia ne fait rien si aucun écran n’est connecté
Les GPU NVidia Quadro peuvent dumper l’EDID d’un moniteur et mapper ce fichier à une sortie, mais les GPU grand public ne le prennent pas en charge
C’est pourquoi un dummy plug est nécessaire
Il suffit d’utiliser l’écran du dummy plug comme sortie PowerPoint, et l’écran du portable pour les notes du présentateur
Ensuite, on partage l’écran du dummy plug
Ce n’est peut-être pas la meilleure réponse pour les lecteurs de Hacker News, mais pour un enseignant ou un commercial, c’est vraiment simple
On peut en avoir besoin pour des configurations de streaming OBS ou de streaming de jeux comme Steam ou Parsec
Il y a quelques années, cela fonctionnait dans une certaine mesure avec Xorg et des pilotes open source sous Linux, ainsi qu’avec Windows et Nvidia, mais pas très bien avec MacOS ou Windows+GPU AMD/Intel
Tromper le système d’exploitation pour lui faire croire qu’un écran est connecté introduit une nouvelle variable qui n’existe pas dans l’environnement réel de déploiement de l’utilisateur ; un dummy plug est une solution matérielle peu coûteuse
Il est probablement plus rentable d’en acheter un et de le brancher que de demander à un ingénieur d’écrire
echo on > /sys/whateveret toute la logique autourJ’ai ajouté en logiciel un faux moniteur 4K à mon bureau pour du streaming de jeu à distance, et c’était bien plus compliqué que prévu
https://pfy.ch/programming/4k-sunshine.html
Astuce intéressante : avec la même procédure, on peut aussi modifier l’EDID stocké dans un moniteur classique ou dans l’écran d’un ordinateur portable
Parfois, on peut même écrire à d’autres adresses I2C pour changer plusieurs paramètres du TCON
Le Raspberry Pi n’est pas indispensable non plus : n’importe quel ordinateur peut faire l’affaire
Je le modifiais pour faire stroboscoper le rétroéclairage LED afin d’obtenir une image sans flou comme sur un CRT
J’ai découvert que le bus DDC exposait aussi d’autres registres contrôlant le rétroéclairage, etc., et j’ai raccordé un circuit externe pour le strobing
J’ai aussi vu les registres permettant de lire et d’écrire la ROM flash ; je l’ai dumpée, puis j’ai écrit un désassembleur 8051 et fait une rétro-ingénierie approximative, avant de modifier finalement la ROM pour y ajouter un mode stroboscopique
J’ai fait en sorte que ce mode occupe la partie basse du réglage de luminosité, afin qu’on puisse l’activer et l’ajuster via l’OSD ou le contrôle de luminosité DDC standard
Pour flasher, il fallait ouvrir l’appareil et connecter la ligne d’écriture
Pratique : il y avait une interruption vblank, et le timer qui contrôlait le rétroéclairage LED avait un mode permettant de l’allumer juste avant l’interruption suivante, puis de l’éteindre après une durée réglable
Le timing était parfait pour allumer le rétroéclairage juste après la stabilisation du rafraîchissement LCD
L’objectif initial était seulement de supprimer le logo de démarrage de quelques secondes, et ça a réussi
Je pense que seuls les produits bas de gamme l’omettent
Sans protection, c’est risqué : un glitch de tension pendant une lecture peut se transformer en écriture et corrompre la flash
« Si vous essayez cette commande sur un PC, vous risquez de flasher accidentellement un matériel qui n’est pas l’EDID, par exemple l’EEPROM SPD d’un module RAM »
Normalement, on achèterait une EEPROM préprogrammée, on la monterait sur la carte, et on câblerait la broche d’activation d’écriture pour qu’elle ne puisse jamais passer à l’état haut
Mettre une EEPROM dans un produit comme un moniteur et la laisser inscriptible est étrange, même si j’ai déjà vu plus bizarre sur du matériel commercialisé
Je suis perplexe
Je m’attendais à voir la fiche connectée aux broches GPIO I2C, mais il semble suffire de la brancher directement au RPi
Je me demande donc si HDMI expose directement une interface I2C
Comme mentionné dans l’article, le RPi dispose d’un contrôleur I2C connecté à ces broches du port HDMI, puisqu’il doit lire l’EDID via DDC
Je me demande si quelqu’un connaît un émulateur EDID DisplayPort bon marché qui permettrait de résoudre les problèmes avec les KVM et Linux.
La dernière fois que j’ai vérifié, c’était tellement plus cher que le HDMI qu’il valait presque mieux acheter un nouveau KVM.
À la place, il utilise le bus AUX haut débit propre à DisplayPort, bien plus complexe à manipuler.
J’ai l’impression qu’il est difficile de trouver une documentation correcte sans adhérer à la VESA et signer une pile de NDA.
https://foosel.net/til/how-to-override-the-edid-data-of-a-mo...
En revanche, si l’objectif est d’ajouter un écran virtuel, je ne sais pas trop si https://askubuntu.com/questions/453109/add-fake-display-when... fonctionne.
Je me demande si les dummy plugs peuvent aussi servir à modifier le fingerprinting des appareils.