2 points par GN⁺ 2025-06-16 | 1 commentaires | Partager sur WhatsApp
  • Présentation d’une méthode simple pour modifier l’EDID d’un plug factice HDMI à l’aide d’un Raspberry Pi
  • Un plug factice sert à faire croire à un appareil qu’un moniteur est connecté, même sans périphérique d’affichage réel
  • En copiant les informations EDID de celles d’un périphérique de capture 1080p, il est possible de configurer le plug pour qu’il ne soit pas détecté comme un moniteur 4K
  • Le contenu de l’EEPROM du plug peut être lu et écrit avec le contrôleur I2C du Raspberry Pi et les outils Linux standard
  • Tout au long du processus, il est indispensable de choisir le bon bus I2C et d’effectuer une sauvegarde afin d’éviter d’endommager le matériel

Vue d’ensemble des plugs factices et de l’EDID

  • Un plug factice est un petit dongle que l’on branche sur un port HDMI ou DVI ; il n’effectue aucun traitement vidéo réel, mais grâce à un circuit minimal, il permet à l’appareil de détecter la connexion d’un moniteur
  • Il contient notamment une puce EEPROM qui imite l’EDID (Extended Display Identification Data) d’un moniteur, ainsi que des résistances de pull-up reliées au +5V
  • C’est utile sur des serveurs headless, des appareils sans supervision et d’autres systèmes où il faut que le système d’exploitation (OS) considère qu’un écran est présent

Objectif et approche

  • Retour d’expérience sur le souhait de modifier l’EDID d’un plug factice HDMI compatible 4K existant afin qu’il soit reconnu comme un simple périphérique 1080p
  • L’objectif était de remplacer l’EDID interne du plug factice par les informations EDID d’un périphérique de capture HDMI prenant en charge le 1080p
  • Il n’était pas certain au départ que l’EEPROM du plug factice autorise l’écriture, mais cela valait la peine d’essayer
  • Le port HDMI d’un Raspberry Pi Zero étant relié au contrôleur I2C, l’accès est simple

Précautions de sécurité et début de la procédure

  • Si l’on effectue ce type de manipulation avec un vrai moniteur connecté, un écran dépourvu de protection EDID risque d’être endommagé
  • Il faut impérativement n’intervenir que sur un appareil acceptable à sacrifier, comme un plug factice
  • Il est également essentiel d’utiliser le bon bus I2C et, avant toute écriture, de lire et vérifier l’EDID au préalable

Configuration de l’environnement et préparation

  • Installation de Raspberry Pi OS Lite, puis ajustement de la configuration avec sudo raspi-config
  • Installation des outils I2C avec sudo apt install i2c-tools (sur un Pi Zero, un accès réseau est nécessaire ; on peut le contourner avec un adaptateur USB-Ethernet ou un chroot sur la carte SD)
  • Utilisation nécessaire d’un adaptateur HDMI vers Mini-HDMI

Détection et sauvegarde de l’EEPROM EDID

  • Sur un Raspberry Pi Zero, utilisation du bus I2C 2 (le numéro diffère selon les autres modèles de Pi)
  • Vérification avec la commande i2cdetect que le périphérique répond à l’adresse 0x50, l’adresse standard d’une EEPROM EDID
  • Fait notable : les adresses 0x51 à 0x57 répondent également, ce qui correspond à une forme de stockage multiple de l’EDID
  • Sauvegarde de l’EDID d’origine du plug factice avec get-edid, puis double lecture pour comparer et vérifier la cohérence
  • Affichage de l’EDID en hexadécimal avec od -v -An -txC, puis validation avec edidreader.com

Extraction de l’EDID du périphérique de capture et écriture dans le plug

  • Débrancher le plug factice, puis connecter le périphérique de capture HDMI au Pi
  • Extraire l’EDID du périphérique de capture de la même manière, puis revérifier sa validité
  • Reconnecter ensuite le plug factice et écrire l’EDID du périphérique de capture dans l’EEPROM
  • L’écriture se fait octet par octet via la commande i2cset, ce qui est possible uniquement avec les outils Linux standard et bash

Vérification finale et résultat

  • Une fois l’opération terminée, réextraire l’EDID du plug factice et le comparer au fichier d’origine avec diff pour confirmer que le contenu correspond
  • Une fois branché sur l’ordinateur de test, le système l’identifie non plus comme le moniteur 4K d’origine, mais comme le périphérique de capture HDMI
  • Le remplacement de l’EDID du plug factice a donc été mené à bien

Conclusion et conseils d’usage

  • La même procédure permettrait aussi de transformer un ancien plug factice 1080p en périphérique compatible 4K
  • Il est recommandé d’effectuer les écritures I2C uniquement depuis un Raspberry Pi ; les faire directement depuis un PC classique présente un risque de dommage matériel
  • Si vous avez besoin de cette fonctionnalité, cette procédure peut s’avérer utile

1 commentaires

 
GN⁺ 2025-06-16
Avis Hacker News
  • Petit conseil pour ceux qui veulent essayer chez eux : la plupart des dummy plugs bon marché n’ont qu’une EEPROM de 256 octets, ce qui ne suffit pas pour stocker tous les blocs d’extension EDID nécessaires aux hautes résolutions et hauts taux de rafraîchissement ; ils ne peuvent simuler que du 1080p60. Par exemple, impossible d’imiter un moniteur 4K240. Et sur certains produits, la ligne de write-protect est déjà câblée, donc il faut intervenir physiquement, par exemple en soudant, pour pouvoir écrire les données
  • L’inconvénient de ces dummy plugs est qu’ils ne gèrent pas le HDCP. C’est excellent pour forcer une machine headless à sortir une certaine résolution, mais inutilisable pour tester des services de streaming qui exigent le HDCP. Est-ce que quelqu’un connaît une solution de dummy plug HDMI capable de négocier aussi le HDCP ? C’est pénible d’utiliser un téléviseur comme matériel de test à chaque fois. Une solution que j’ai trouvée est le multiviewer HDMI, qui négocie le HDCP séparément sur chaque port
    • J’utilise un splitter HDMI : on peut soit définir un EDID préprogrammé, soit apprendre l’EDID depuis le moniteur branché sur la sortie HDMI 1, et tant que le splitter est alimenté, il se comporte comme si un moniteur était connecté, même sans écran réel. Le splitter négocie le HDCP avec le PC ou la console, puis transmet le signal vers le vrai moniteur sans HDCP ; voir amazon.com
    • On voit aussi beaucoup d’annonces sur Aliexpress pour des appareils vendus comme capables de terminer le HDCP puis de faire passer le HDMI ; mieux vaut être prudent avant achat
    • Retirer le HDCP n’est pas simple : cela consiste à rétrograder en HDCP 1.4 puis à connecter un appareil « compliant » compatible avec la spécification 1.4 pour s’en servir comme dummy monitor. Si du HDCP 1.4 ou plus est requis, c’est presque impossible
    • J’ai un système embarqué avec une sortie HDMI, et je voudrais remplacer l’écran de démarrage par un autre flux HDMI, même une image statique suffirait. Il est absolument impossible de toucher au système embarqué lui-même. Il me faut un moyen économique et robuste de ne modifier que le signal HDMI
    • Je recommande d’essayer les splitters HDMI vendus sur Amazon qui sont, de fait, commercialisés comme des « HDCP strippers »
  • Je me demande s’il existe quelque part une collection de fichiers binaires EDID, ou un programme pratique pour en créer. J’utilise un plug émulateur EDID programmable, mais il est difficile voire impossible d’y configurer directement certaines résolutions ou fonctions précises, par exemple une résolution 8K avec DSC. github.com/bsdhw/EDID manque d’informations sur les moniteurs récents. J’ai aussi essayé d’en créer moi-même avec AnalogWay EDID Editor, mais le réglage fin des modes pris en charge, des subtiles différences entre eux ou de leur priorité n’est pas facile
    • J’ai eu un problème similaire : j’ai acheté une soundbar 5.1 bon marché qui prend même en charge le Dolby TrueHD, mais la connexion HDMI ne fonctionne qu’avec un appareil compatible eArc, donc un téléviseur récent. Si je branche un PC, je dois me contenter du SPDIF ou de l’aux, ce qui dégrade la qualité sonore. Au lieu d’un extracteur/splitter audio, j’essaie de modifier la valeur edid du PC pour que la soundbar le reconnaisse comme un appareil eArc ; il ne semble pas encore exister de guide vraiment strict sur le sujet
  • On peut aussi acheter des dummy plugs avec fonction passthrough, ce qui est utile quand un ancien système a des problèmes de compatibilité avec un moniteur haute résolution. Par exemple, mon système AMD FX8350 de 2011 a des soucis en sortie 4K, donc si j’insère un plug en ligne pour forcer le 1080p, le moniteur upscale automatiquement en 2x et l’affiche proprement en 4K
    • J’ai aussi quelques appareils passthrough, j’aurais dû mentionner cette option dans le billet. Le mien est un peu particulier : il lit et stocke l’EDID du moniteur, puis peut l’appliquer en override sur un autre moniteur. Autre point intéressant : il peut forcer la détection d’un moniteur comme toujours connecté. Un de mes moniteurs passe virtuellement en état débranché quand je l’éteins, ce qui cause des problèmes ; l’appareil passthrough corrige parfaitement ça. Le produit que j’utilise est le HD-EWB de THWT
  • Il est aussi possible de modifier avec cette méthode les informations edid stockées dans un moniteur classique ou dans l’écran d’un portable. Plusieurs réglages du TCON peuvent également être modifiés en écrivant sur d’autres adresses i2c. Un Raspberry Pi n’est même pas nécessaire, n’importe quel ordinateur peut faire l’affaire
    • L’auteur du billet recommande bien un Pi, mais ce n’est pas indispensable ; si on suit simplement la procédure depuis un PC, on risque de flasher par erreur autre chose que l’EDID, par exemple l’EEPROM SPD des barrettes de RAM
    • Les puces flash ont un pin séparé d’activation/désactivation de l’écriture, et la plupart des moniteurs ou téléviseurs sont câblés pour bloquer l’écriture de l’edid. J’imagine que seuls les modèles d’entrée de gamme laissent ça ouvert. Si ce n’est pas protégé, un simple bruit de tension pendant la lecture peut déclencher une écriture et corrompre la flash
    • Le fait qu’on puisse modifier l’edid sur la plupart des moniteurs révèle surtout une faille du côté des fabricants de matériel. En général, on reçoit une EEPROM préprogrammée et on laisse le pin d’écriture à l’état haut. Expédier un produit avec l’écriture activée n’est pas une conception courante, mais sur le terrain on rencontre parfois des cas inattendus
  • Pourquoi a-t-on besoin d’un dummy plug ? Je me demande s’il existe quelque chose qu’on ne peut pas résoudre par logiciel ; moi, j’utilise 18 écrans virtuels sans aucun problème en logiciel
    • Un cas concret : j’utilise le logiciel Looking Glass sur mon PC pour piloter une machine virtuelle Windows. J’ai deux GPU, AMD et NVidia, et la carte NVidia est passée en passthrough à la VM Windows. Looking Glass affiche la sortie du GPU NVidia dans une fenêtre sur le bureau, ce qui me permet d’utiliser les programmes Windows de la VM sans perte de performances — depuis Windows 7, c’est difficilement utilisable sans accélération GPU. Le problème, c’est que le GPU NVidia ne fonctionne que si un vrai écran est connecté. Les GPU Quadro peuvent dumper le fichier EDID d’un moniteur et simuler une connexion permanente, mais les GPU grand public n’offrent pas cette fonction. Dans ce cas, le dummy plug est la seule alternative
    • Selon la combinaison OS / GPU / pilote, la liberté de configuration des écrans virtuels varie énormément. Pour ajouter un écran destiné à OBS ou au streaming de jeu via Steam/Parsec, un dummy plug est bien plus simple. Cela peut marcher avec Linux + Xorg + pilotes open source ou avec Windows + Nvidia, mais presque jamais avec macOS ou Windows + GPU AMD/Intel
    • J’utilise un Chromebox modifié pour faire tourner Windows/Linux, et s’il n’y a aucun périphérique vidéo sur le port HDMI, il ne démarre tout simplement pas. Sans dummy plug, on est bloqué
    • Un dummy plug est bien plus simple et pratique pour le grand public. Configurer uniquement par logiciel un moniteur virtuel 4K pour du streaming de jeu à distance est beaucoup plus complexe qu’on ne l’imagine ; voir configurateur 4k-sunshine
    • Sur le bureau à distance du Raspberry Pi, le bureau n’est rendu que si un moniteur physique est effectivement connecté ; pour un doctorant fauché et pressé, le dummy plug est parfait
  • Je me demande s’il existe un émulateur EDID DisplayPort bon marché qui tienne la route pour résoudre ce genre de problème en environnement KVM et Linux. Par rapport aux versions HDMI, les prix sont tellement élevés qu’il vaut presque mieux racheter un KVM
    • Avec DisplayPort, il ne s’agit pas simplement d’écrire dans l’EEPROM d’un bus I2C : on passe par le bus AUX propre à DisplayPort, ce qui est beaucoup plus complexe. Il est aussi difficile de trouver une documentation publique correcte, et pour obtenir de vraies références il faut adhérer à la VESA et signer un NDA
  • Le résultat du hex dump du plug USB ibus2 est suivi de l’EDID