Pourquoi 640×480 semble éternel : des normes qui refusent de disparaître

Le « mode éternel » : pourquoi 640×480 continue de l’emporter

640×480 n’est pas seulement une résolution. C’est une trêve. Quand une chaîne d’affichage ne parvient pas à se mettre d’accord sur ce qu’elle est, ce qu’elle peut faire ou ce que l’autre côté peut faire, elle retombe sur quelque chose qui marche presque toujours. En production, « marche presque toujours » bat « généralement une résolution plus élevée » à chaque fois.

Les normes ne meurent pas parce qu’elles sont anciennes. Elles meurent quand elles deviennent gênantes. VGA n’a jamais été gênant. C’était peu coûteux. C’était compris. C’était compatible avec tout, du firmware d’époque BIOS aux commutateurs KVM d’entreprise qui ont vu plus de déménagements de racks que votre architecte principal. Il possède aussi une qualité que les équipes d’exploitation apprécient discrètement : on obtient quelque chose à l’écran même quand tout le reste brûle.

Les raisons pour lesquelles 640×480 « gagne » sont rarement une question de goût. Ce sont des échecs de négociation :

• EDID n’est pas disponible ou n’est pas fiable, donc le GPU choisit un mode par défaut sûr.
• Un KVM ou un adaptateur ment (ou « assainit » l’EDID de façon « utile »), de sorte que vous ne voyez jamais les capacités réelles de l’écran.
• Le firmware utilise des chemins GOP/VGA hérités conservateurs pendant le démarrage, et vous le remarquez lors du travail sur console distante.
• Le noyau ou le pilote se charge tard, donc la console précoce reste en mode minimal jusqu’à ce que l’espace utilisateur corrige le problème.
• Les consoles virtuelles et hors bande émulant des hypothèses anciennes pour une compatibilité maximale.

Ce dernier point est celui que les ingénieurs sous-estiment : l’« écran » que vous regardez n’est peut-être pas votre périphérique d’affichage réel. Cela peut être le visualiseur HTML5 d’un BMC, un flux KVM IPMI, le GPU virtuel d’un hyperviseur, ou un appareil de capture qui préfère faire comme en 2004.

Première vérité crue : 640×480 est rarement le problème primaire. C’est le symptôme diagnostique qui dit « le réglage du mode a échoué quelque part ». Votre travail est de trouver où, puis décider s’il faut réparer la négociation, la remplacer, ou contourner le problème.

Une petite blague pour détendre : 640×480, c’est comme ce collègue qui n’apprend jamais de nouveaux outils mais qui a quand même accès à la production.

Faits et historique qui expliquent ce bazar

Quelques faits concrets—courts, dépouillés et utiles—expliquent pourquoi cette norme refuse de prendre sa retraite.
Ce ne sont pas des anecdotes : ils correspondent directement aux modes de défaillance que vous verrez sur le terrain.

1. VGA d’IBM (1987) a popularisé 640×480 comme base graphique commune et interopérable. L’industrie a copié cette base parce que l’interopérabilité se vend.
2. VESA créé en 1989 pour normaliser les modes d’affichage et les timings, car les vendeurs envoyaient des signaux « presque compatibles » qui rendaient les moniteurs tristes.
3. VESA DDC et EDID (années 1990) ont permis aux écrans de se décrire eux-mêmes via I²C, afin que les systèmes choisissent automatiquement les modes—jusqu’à ce que le câble, le KVM ou l’adaptateur casse ce petit canal latéral.
4. Des résolutions « mode sûr » existent parce qu’un mode hors-plage peut produire aucune image du tout, ce qui en termes d’exploitation est indiscernable d’« le serveur est mort ».
5. Les services vidéo de l’ère BIOS ont maintenu les hypothèses VGA vivantes dans le firmware et les bootloaders ; l’UEFI n’a pas effacé ces attentes du jour au lendemain.
6. Le VGA analogique est indulgent sur la qualité du signal comparé à certains entraînements de lien numériques et attentes de handshake ; « indulgent » compte sur de longues liaisons et des prolongateurs bon marché.
7. Les commutateurs KVM d’entreprise ont historiquement privilégié la compatibilité plutôt que le passage parfait de l’EDID. Certains mettent en cache un EDID et le présentent à chaque serveur.
8. Les adaptateurs HDMI-vers-VGA sont des convertisseurs actifs qui doivent inventer un signal analogique à partir de données numériques ; beaucoup sont livrés avec un support EDID minimal et des tables de timing discutables.
9. Les graphiques en tout début de démarrage arrivent souvent avant la pile complète de pilotes. Si le firmware choisit 640×480, vous le verrez jusqu’à ce que KMS/l’espace utilisateur reprogramme l’affichage.

Le schéma : les anciennes normes persistent quand elles deviennent la couche d’interopérabilité de dernier recours.
Une fois que l’écosystème entier s’accorde sur un « plancher », ce plancher devient un filet de sécurité opérationnel.

La pile de normes : VGA, VESA, EDID, DDC, GOP, KMS

VGA : la base que le firmware comprend encore

VGA est à la fois une histoire de connecteur et une histoire de signalisation, et les gens les confondent constamment.
« VGA » peut signifier :

• RGB analogique sur DE-15 (le connecteur bleu), plus les signaux de synchronisation.
• Un ensemble de modes : timings canoniques comme 640×480 à 60 Hz.
• Une couche de compatibilité dans le firmware : « Je peux toujours afficher du texte et peut-être des pixels. »

Pourquoi le firmware l’aime : c’est simple, bien compris, et ça ne nécessite pas de négociation.
C’est pourquoi vous voyez encore un comportement de type VGA au tout début du démarrage, même sur des systèmes qui n’ont jamais eu de port DE-15.

Modes VESA et pourquoi le timing importe

Une « résolution » est incomplète sans taux de rafraîchissement et timing précis. Les moniteurs se préoccupent des horloges pixel,
des largeurs de synchronisation, des intervalles de blanking—des détails dont vous ne voulez pas vous soucier en pleine résolution d’incident.
VESA a créé des formules de timing standardisées pour que les GPUs et les moniteurs s’accordent sur ce que signifie électriquement « 1024×768 @ 60 ».

Quand la négociation de mode échoue, les systèmes choisissent souvent un timing établi et conservateur : 640×480 @ 60.
Il est moins susceptible d’être hors-plage, moins susceptible d’exiger des horloges exotiques, et plus susceptible d’apparaître dans l’EDID
même quand l’EDID est incomplet.

EDID et DDC : le « petit fil » qui décide de votre journée

L’EDID (Extended Display Identification Data) est l’auto-description du moniteur : résolutions supportées,
timing préféré, identifiants vendeur/produit, et parfois des blocs supplémentaires pour l’audio ou le HDR.
Il est généralement transporté via DDC, un canal I²C greffé sur le connecteur d’affichage.

Voici le point opérationnel : l’EDID est une dépendance. Il peut manquer, être corrompu, mis en cache ou remplacé.
Et les systèmes qui en dépendent—firmware, noyaux, Xorg/Wayland, consoles distantes—ont chacun leur propre comportement de repli.

UEFI GOP vs VGA hérité

Le firmware moderne utilise GOP (Graphics Output Protocol) pour fournir un framebuffer aux bootloaders.
Si GOP initialise à une faible résolution (parfois basée sur une lecture EDID simpliste), votre sortie de démarrage précoce
aura l’air d’une pièce de musée. Une fois que la pile graphique de l’OS se charge, elle peut reprogrammer l’affichage,
mais seulement si elle peut lire les capacités et appliquer un mode supporté.

DRM/KMS Linux : quand « ça devrait juste marcher » rencontre la réalité

DRM/KMS (Direct Rendering Manager / Kernel Mode Setting) signifie que le noyau règle les modes d’affichage tôt,
plutôt que d’attendre l’espace utilisateur. Cela rend généralement le démarrage plus fluide et évite les scintillements de mode.
Mais cela signifie aussi qu’une mauvaise lecture EDID peut vous enfermer dans un mode de repli avant que l’espace utilisateur n’ait la chance de corriger.

Si vous retenez une chose : quand vous voyez 640×480, demandez « quelle couche l’a choisi ? » Firmware ? Noyau ? Xorg/Wayland ?
Console distante ? KVM ? Adaptateur ? Voilà toute l’enquête.

Une citation, parce que l’ingénierie de fiabilité aime humilier les suppositions confiantes :
« L’espoir n’est pas une stratégie. » — Gene Kranz

Où 640×480 apparaît encore dans l’exploitation réelle

1) Crash carts et le tiroir « KVM mystère »

Vous connaissez le tiroir. Celui avec des câbles VGA non étiquetés, un adaptateur DisplayPort d’un fournisseur disparu,
et un commutateur KVM qui « marche toujours ». C’est là que l’EDID devient étrange.

Beaucoup de crash carts incluent un KVM qui met en cache soit un EDID indéfiniment, soit qui présente un EDID générique à chaque système connecté.
Un EDID générique inclut souvent des timings établis et conservateurs, et 640×480 est la plus sûre des options sûres.

2) Consoles distantes hors bande (BMC/IPMI/KVM-over-IP)

Les BMC implémentent souvent une chaîne d’affichage virtuelle, capturant la sortie vidéo et la réencodant pour la visualisation distante.
Certains BMC ne gèrent qu’un sous-ensemble de modes correctement. D’autres maltraitent le hotplug ou l’EDID quand vous ouvrez la console distante.

Le résultat : votre serveur rend peut-être 1920×1080 localement, mais la console distante force une redétection,
et soudain l’OS bascule à 640×480 parce qu’il croit que le moniteur a disparu.

3) Adaptateurs HDMI/DP vers VGA dans salles de réunion et laboratoires

Ces adaptateurs sont des dispositifs actifs. Ils ont un firmware. Ils peuvent mentir. Ils peuvent aussi « résoudre » l’EDID en n’annonçant
que quelques modes pour éviter des appels de support. Si 640×480 n’apparaît que lorsque l’adaptateur est dans la chaîne, croyez le motif.

4) Systèmes sans affichage prétendant en avoir un

Les serveurs headless ont parfois besoin d’un framebuffer pour les installateurs, pour les consoles iDRAC/iLO, ou pour des environnements GPU compute.
Sans écran physique, le GPU peut rapporter « pas de connecteurs » ou synthétiser un mode minimal.
Une clé fantôme qui fournit l’EDID peut résoudre cela instantanément—à condition qu’elle fournisse un EDID raisonnable.

5) Virtualisation et consoles imbriquées

Une VM peut utiliser un GPU virtuel avec une liste de modes fixe. Une console d’hyperviseur peut forcer un mode de repli.
Ou votre client RDP/VNC peut avoir ses propres bizarreries de négociation. Si votre « moniteur » est un visualiseur logiciel,
traitez-le comme un KVM : il peut devenir le maillon le plus faible.

Manuel de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

C’est la liste de contrôle que je veux afficher quand quelqu’un signale « console bloquée à 640×480 » et que la fenêtre de changement se referme.
L’objectif : identifier si le goulot est liaison physique, EDID, firmware, pilote noyau ou espace utilisateur.

Premier : la chaîne d’affichage ment-elle ?

• Contournez le KVM/prolongateur/adaptateur. Branchez directement avec un câble connu vers un écran connu.
• Changez le câble et le port. Préférez une liaison numérique bout en bout (DP/HDMI) si possible.
• Si console distante : essayez un écran local ; si local c’est bon, la « sortie d’affichage » est la pipeline BMC.

Second : l’EDID est-il lisible et cohérent ?

• Sur Linux, vérifiez l’état du connecteur DRM et la présence d’EDID dans sysfs.
• Cherchez « EDID checksum is invalid » ou « failed to read EDID » dans les logs du noyau.
• Si l’EDID manque : suspectez le KVM, l’adaptateur, des câbles longs, ou des problèmes sur la broche DDC.

Troisième : quelle couche a défini 640×480 ?

• Seulement au démarrage ? Le firmware/GOP l’a choisi. L’OS peut être correct une fois complètement démarré.
• Reste bas à l’écran de connexion graphique ? Pilote noyau ou sélection de mode en espace utilisateur.
• Change quand on ouvre la console distante ? Hotplug/redétection EDID déclenché par le BMC/KVM.

Quatrième : décider de réparer la négociation ou forcer un mode

• Si c’est transitoire ou dépendant de la chaîne : réparez la chaîne (pass-through EDID, meilleur KVM, chemin DDC plus court).
• Si c’est headless par conception : utilisez un override EDID correct ou une clé dongle EDID connue.
• Si c’est un système ponctuel dans un rack : forcer un mode peut être acceptable, mais documentez-le comme une mine.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Voici des tâches réelles que vous pouvez exécuter sur un hôte Linux pour diagnostiquer et corriger la classe de problèmes « bloqué à 640×480 ».
Chaque tâche inclut : commande, ce que signifie la sortie, et la décision qu’elle entraîne. Exécutez-les en root quand nécessaire.

Task 1: See what the kernel thinks the connectors are doing

cr0x@server:~$ ls -1 /sys/class/drm/
card0
card0-DP-1
card0-HDMI-A-1
card0-eDP-1
renderD128
version

Signification : Chaque entrée card0-* est un connecteur. Si vous ne voyez pas le connecteur attendu, vous ne déboguez pas la « résolution » — vous déboguez la détection.

Décision : Si le connecteur est absent, concentrez-vous sur le pilote/module/firmware et le câblage physique, pas sur les lignes de mode.

Task 2: Check connector status (connected/disconnected)

cr0x@server:~$ for c in /sys/class/drm/card0-*/status; do echo "$(basename "$(dirname "$c")"): $(cat "$c")"; done
card0-DP-1: disconnected
card0-HDMI-A-1: connected
card0-eDP-1: disconnected

Signification : Le noyau voit HDMI-A-1 comme connecté. S’il indique disconnected alors que vous avez un écran, vous regardez probablement un chemin distant/BMC.

Décision : S’il oscille entre connected/disconnected, suspectez un câble défectueux, un comportement de hotplug du KVM, ou un comportement d’économie d’énergie du moniteur/KVM.

Task 3: Read supported modes from sysfs

cr0x@server:~$ cat /sys/class/drm/card0-HDMI-A-1/modes | head
640x480
800x600
1024x768
1280x720
1920x1080

Signification : Voilà ce que DRM croit valide pour ce connecteur. Si seule la ligne 640×480 apparaît, l’EDID est absent/filtré ou le pilote est retombé sur une liste intégrée minuscule.

Décision : Si la liste des modes est suspectement courte, passez à la vérification de l’EDID et aux logs du noyau.

Task 4: Check whether EDID exists for the connector

cr0x@server:~$ ls -l /sys/class/drm/card0-HDMI-A-1/edid
-r--r--r-- 1 root root 256 Jan 21 10:14 /sys/class/drm/card0-HDMI-A-1/edid

Signification : Un blob EDID existe. Cela ne garantit pas qu’il est correct, mais c’est un bon signe.

Décision : Si le fichier est absent ou de taille 0, suspectez des problèmes DDC/EDID (KVM, adaptateur, câble).

Task 5: Decode EDID to confirm preferred mode and sanity

cr0x@server:~$ edid-decode /sys/class/drm/card0-HDMI-A-1/edid | sed -n '1,40p'
edid-decode (hex):
00 ff ff ff ff ff ff 00 4c 2d 07 0c 01 01 01 01
...
Manufacturer: SAM Model 3079 Serial Number 16843009
Made in week 1 of 2018
...
Display Product Name: S24D330
...
Preferred timing: 1920x1080p at 60 Hz

Signification : Vous avez un EDID valide avec un timing préféré. Si le système choisit toujours 640×480, le problème est probablement lié à la politique de sélection de mode, aux limites du pilote, ou à un événement hotplug ultérieur.

Décision : Si l’EDID ne contient que des modes bas ou se décode avec des avertissements de checksum, remplacez le lien suspect (KVM/adaptateur) ou surchagez l’EDID.

Task 6: Search kernel logs for EDID and modesetting errors

cr0x@server:~$ dmesg -T | egrep -i 'drm|edid|hdmi|dp|vga|modeset' | tail -n 20
[Tue Jan 21 10:13:02 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Tue Jan 21 10:13:03 2026] [drm:intel_hdmi_detect [i915]] HDMI-A-1: EDID read succeeded
[Tue Jan 21 10:13:03 2026] [drm:intel_hdmi_compute_config [i915]] requested mode 640x480 rejected, falling back
[Tue Jan 21 10:13:04 2026] [drm] fb0: i915drmfb frame buffer device

Signification : Le log vous indique si les lectures EDID ont réussi et si la validation du mode a échoué.

Décision : Si des modes sont rejetés, vérifiez les limites du pilote, les contraintes d’horloge pixel, et si le mode demandé est réellement supporté par la chaîne de connecteurs.

Task 7: See what Xorg/Wayland thinks (X11 example with xrandr)

cr0x@server:~$ xrandr --verbose | sed -n '1,120p'
Screen 0: minimum 320 x 200, current 640 x 480, maximum 8192 x 8192
HDMI-1 connected primary 640x480+0+0 (0x48) normal (normal left inverted right x axis y axis) 477mm x 268mm
  1920x1080 (0x4a) 148.500MHz +HSync +VSync *preferred
  1280x720  (0x4b) 74.250MHz +HSync +VSync
  640x480   (0x48) 25.175MHz -HSync -VSync

Signification : X voit 1920×1080 comme préféré mais est actuellement en 640×480. Cela signifie généralement un choix de politique, une tentative échouée de définir le mode, ou une course avec un événement hotplug.

Décision : Essayez de passer au mode préféré ; si cela échoue, cherchez des erreurs de pilote et une instabilité de l’EDID.

Task 8: Force a mode temporarily (X11) to validate capability

cr0x@server:~$ xrandr --output HDMI-1 --mode 1920x1080 --rate 60
cr0x@server:~$ xrandr | head -n 3
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
HDMI-1 connected primary 1920x1080+0+0 normal (normal left inverted right x axis y axis)
DP-1 disconnected

Signification : Le changement de mode fonctionne en espace utilisateur. S’il revient plus tard à 640×480, quelque chose déclenche une redétection (hotplug KVM, gestion d’énergie, ouverture/fermeture de console distante).

Décision : S’il bascule en arrière, concentrez-vous sur la stabilité : désactivez les événements hotplug problématiques, réparez le KVM ou utilisez un override EDID.

Task 9: Check if you’re on a BMC virtual console path

cr0x@server:~$ dmidecode -t system | egrep -i 'manufacturer|product'
Manufacturer: Supermicro
Product Name: X11SSH-F

Signification : Identifie une plateforme serveur susceptible d’avoir un BMC. Ce n’est pas une preuve, mais un indice que vous pouvez être en train de visualiser via KVM-over-IP avec ses propres contraintes.

Décision : Si la console distante se comporte différemment de l’écran local, traitez le BMC comme faisant partie de la chaîne d’affichage et testez les deux chemins.

Task 10: Confirm which driver is in use and whether KMS is active

cr0x@server:~$ lspci -k | sed -n '/VGA compatible controller/,+6p'
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Desktop)
	Subsystem: Dell Device 087c
	Kernel driver in use: i915
	Kernel modules: i915

Signification : Confirme le pilote du noyau. Si vous voyez un pilote générique (comme vesa dans certains contextes) vous pouvez être coincé dans un chemin de repli qui limite les modes.

Décision : Si le pilote correct n’est pas chargé, corrigez cela d’abord ; aucun xrandr ne compensera un mauvais module noyau.

Task 11: Inspect DRM debug state for mode validation clues

cr0x@server:~$ cat /sys/kernel/debug/dri/0/i915_display_info 2>/dev/null | head -n 30
CRTC info
  CRTC 0: active yes (pipe A)
  connector HDMI-A-1: connected
    max bpc: 12
    link-status: GOOD
    modes:
      1920x1080@60
      1280x720@60
      640x480@60

Signification : Le debug spécifique au pilote peut montrer l’état du lien et les listes de modes que le pilote accepte d’utiliser.

Décision : Si link-status est mauvais ou si des modes manquent ici mais sont présents ailleurs, vous avez un problème de pilote/entraînement de lien, pas un problème d’environnement de bureau.

Task 12: Check whether a kernel boot parameter is forcing low resolution

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0 root=/dev/mapper/vg0-root ro quiet splash video=HDMI-A-1:640x480@60

Signification : Quelqu’un a forcé le mode via video=. C’est courant après des « correctifs temporaires » devenus permanents.

Décision : Retirez ou ajustez le paramètre si la chaîne matérielle supporte désormais un meilleur mode ; sinon documentez pourquoi il existe et ce qui en dépend.

Task 13: Force a known-good mode early with DRM (temporary test)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=HDMI-A-1:1920x1080@60"/' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.0
done

Signification : Vous demandez au noyau de choisir un mode spécifique sur ce connecteur.

Décision : Utilisez ceci comme test contrôlé. Si cela fonctionne, la négociation était le problème. Si cela échoue (écran noir), revenez en arrière et réparez l’EDID/le câblage au lieu de forcer brutalement.

Task 14: Capture EDID to a file for comparison across cables/KVMs

cr0x@server:~$ sudo cat /sys/class/drm/card0-HDMI-A-1/edid > /tmp/hdmi.edid
cr0x@server:~$ sha256sum /tmp/hdmi.edid
8f7c5d2b1b8a8b5e2c0c0b44f1b1c4f2a0a7b6a3c9d2a1e8d4c0f1a2b3c4d5e6  /tmp/hdmi.edid

Signification : Le hash vous permet de détecter quand l’EDID change entre « moniteur direct » et « via KVM », ce qui est souvent toute l’affaire.

Décision : Si le hash EDID change selon la chaîne, arrêtez de vous battre avec le logiciel et remplacez/upgradez la chaîne ou configurez correctement l’émulation EDID.

Task 15: Validate whether the issue is only in the text console

cr0x@server:~$ fgconsole
1
cr0x@server:~$ cat /sys/class/graphics/fb0/virtual_size
640,480

Signification : Votre console framebuffer est réglée sur 640×480. La session graphique peut encore changer plus tard, mais si elle ne le fait pas, cela indique que KMS/le modesetting précoce est bloqué en bas.

Décision : Si vous avez besoin de consoles lisibles pendant une réponse d’incident, réglez un meilleur mode précoce ou basculez sur la console série lorsque c’est approprié.

Task 16: Detect hotplug storms (often caused by KVMs)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'hotplug|link-status|HDMI|DP|drm' | tail -n 30
Jan 21 10:21:14 server kernel: [drm] HDMI-A-1: Hotplug event received
Jan 21 10:21:15 server kernel: [drm] HDMI-A-1: EDID read failed
Jan 21 10:21:15 server kernel: [drm] HDMI-A-1: using fallback mode 640x480

Signification : Le système perd l’EDID lors du hotplug. C’est un comportement classique des KVM (ou d’un adaptateur instable) et explique « ça revient à 640×480 aléatoirement ».

Décision : Réparez la chaîne physique ou utilisez un émulateur/dongle EDID ; ne continuez pas à lutter avec les réglages de bureau.

Deuxième petite blague, puis on retourne au travail : EDID signifie « Eventually Displays In 640×480 » quand vous mettez un KVM bon marché entre les deux.

Trois mini-récits d’entreprise (anonymisés, plausibles, techniquement exacts)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau kit « standard » de crash cart dans plusieurs halls de données. Le kit avait belle allure :
un tiroir 1U, un écran, un KVM compact et un sac d’adaptateurs pour couvrir tout. Il a passé les tests en laboratoire. Il a passé le pilote. Puis il a rencontré la réalité : un mélange de fournisseurs GPU, de versions de firmware, et de racks avec des prolongateurs KVM déjà en place.

La mauvaise hypothèse était simple : « Si l’écran marche directement, il marchera via le KVM. » Le nouveau KVM a mis en cache l’EDID du premier écran qu’il a vu lors de la configuration, puis a servi cet EDID à tous les serveurs pour toujours. Dans un hall, le premier écran branché était une unité plus ancienne qui annonçait une liste de modes minimale. Le KVM a fidèlement cloné cette médiocrité en aval.

L’incident s’est produit lors d’une fenêtre de maintenance où les ingénieurs avaient besoin d’accès au BIOS sur une série de serveurs. La moitié des machines n’affichaient que 640×480, et l’UI du BIOS est devenue un carnaval défilant. Les ingénieurs ont mal lu des éléments de menu, ont basculé le mauvais mode SATA sur quelques machines, et ont créé une cascade d’échecs de démarrage évitable. Rien d’exotique n’a cassé. Les humains l’ont cassé, aidés par une interface basse résolution et un calendrier serré.

La correction n’a pas été « définir une résolution plus élevée ». La correction a été opérationnelle : standardiser la chaîne crash cart, verrouiller l’EDID du KVM sur un profil connu bon, et documenter le processus pour réinitialiser les caches EDID lors du changement d’écrans. Aussi : cesser de mélanger prolongateurs et KVM sauf si vous pouvez prouver le pass-through EDID bout en bout. Si votre chaîne d’affichage est état‑ful, traitez-la comme une dépendance de production.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a essayé d’« optimiser » le dépannage à distance en poussant tout le monde à utiliser les consoles distantes BMC plutôt que les crash carts. Le plan était raisonnable : moins de personnes dans la salle serveurs, réponse plus rapide, meilleurs logs. Quelqu’un a remarqué qu’à des résolutions plus élevées, la console distante était lente. Ils ont donc réglé la sortie graphique de démarrage des serveurs sur un mode plus bas pour rendre le flux vidéo distant plus léger et « plus réactif ».

Cela a effectivement allégé le flux. Cela a aussi rendu les ingénieurs aveugles. Plusieurs tâches de maintenance critiques reposaient sur la lecture d’entrées bootloader en largeur complète et de sorties de kernel panic. En 640×480, les lignes se coupaient de manière imprévisible. Les gens ont commencé à copier des paramètres erronés. Quelques machines ont été démarrées avec de mauvais réglages de périphérique racine. L’incident n’a pas été dramatique ; il a été pire : une fuite lente de temps, d’erreurs et de redémarrages inutiles sur plusieurs rotations d’astreinte.

Le retour de bâton a été subtil : l’« optimisation » a amélioré une métrique (réactivité du flux distant) tout en dégradant l’objectif réel (récupération réussie). L’organisation avait optimisé pour la bande passante et le CPU du pipeline BMC, pas pour la correction humaine sous stress. Une console lisible est une fonctionnalité de fiabilité.

Ils ont annulé le changement et mis en place une meilleure solution : conserver une résolution lisible (souvent 1024×768 ou 1280×1024) et réduire la charge d’encodage BMC via des réglages qui ne détruisent pas l’utilisabilité. Ils ont aussi déplacé les chemins de récupération critiques vers la série sur LAN pour la sortie texte, ce qui n’est pas joli mais prévisible et scriptable.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait une règle douloureusement conservatrice : chaque rack doit disposer d’au moins un câble numérique direct connu‑bon (sans adaptateurs), et chaque crash cart doit porter un petit dongle émulateur EDID qui annonce une liste de modes validée.
Personne n’aimait ça. Les achats ont demandé pourquoi ils achetaient des « gadgets bizarres ». Les ingénieurs en ont ri. Puis ça a payé.

Lors d’un événement d’alimentation du site, plusieurs KVM ont redémarré dans leurs états par défaut et ont commencé à présenter un EDID générique aux hôtes en aval. Une sous‑ensemble de serveurs est retombé à 640×480 pendant le démarrage précoce. L’équipe d’astreinte devait accéder aux paramètres du firmware sur quelques machines qui étaient revenues en mode RAID dégradé. La basse résolution rendait l’UI du firmware à peine navigable via la chaîne KVM.

Au lieu de déboguer sur le moment, ils ont exécuté la pratique ennuyeuse : contourner le KVM, attacher le câble direct connu‑bon, et si le serveur était headless ou capricieux, insérer l’émulateur EDID. La liste de modes s’est stabilisée. L’UI du firmware est redevenue lisible. L’équipe a pris des décisions correctes rapidement.

Le « sauvetage » n’a pas été de l’ingénierie magique. C’était une trappe de secours planifiée. En production, ennuyeux est un compliment. Tout ce qui convertit de manière fiable « inconnu étrange » en « baseline connue » vaut la peine d’être gardé, documenté et pratiqué.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: only 640×480 is available in the mode list

Cause racine : EDID non lisible (DDC cassé), ou KVM/adaptateur présentant un EDID minimal.

Fix : Contournez la chaîne ; confirmez la présence d’EDID dans /sys/class/drm/*/edid. Remplacez le câble/KVM/adaptateur ou utilisez un émulateur/override EDID.

2) Symptom: preferred mode exists, but system boots at 640×480 and stays there

Cause racine : Paramètres de démarrage du noyau forçant un mode bas ; espace utilisateur n’effectue pas le modeset ; pilote coincé dans le repli.

Fix : Vérifiez /proc/cmdline. Retirez video=...:640x480 ou définissez le mode souhaité. Assurez-vous que le pilote GPU correct est chargé.

3) Symptom: resolution is fine locally, but remote console triggers drop to 640×480

Cause racine : BMC/KVM-over-IP déclenche hotplug ou relecture EDID ; lecture EDID échoue de manière intermittente.

Fix : Cherchez des événements hotplug dans journalctl -k. Stabilisez l’EDID avec un émulateur ou configurez le KVM pour maintenir l’EDID actif.

4) Symptom: screen goes blank when forcing 1080p, but 640×480 works

Cause racine : La chaîne ne supporte pas l’horloge pixel ou le timing (prolongateur bon marché, longue liaison VGA, convertisseur faible).

Fix : Choisissez un mode intermédiaire (1024×768 ou 1280×720) et remplacez le maillon faible. Ne forcez pas un mode hors‑spec pour la chaîne.

5) Symptom: random flips between 640×480 and higher resolution

Cause racine : Tempêtes de hotplug ou veille du moniteur provoquant une perte transitoire d’EDID ; broches DDC du câble défaillantes.

Fix : Remplacez d’abord le câble. Ensuite retirez le KVM/prolongateur de la chaîne. Confirmez la stabilité en comparant les hashes EDID au fil du temps.

6) Symptom: only text console is 640×480, graphical session is fine

Cause racine : Console de démarrage bloquée avec un framebuffer sélectionné par le firmware ; plus tard, l’espace utilisateur effectue correctement le modeset.

Fix : Si vous tenez à un affichage lisible pendant le démarrage, définissez video= du noyau sur un mode raisonnable ou configurez la résolution GOP du firmware si disponible.

7) Symptom: different servers on same monitor/KVM behave differently

Cause racine : Différents pilotes GPU valident les modes différemment ; versions firmware lisent l’EDID différemment ; certains pilotes sont plus stricts sur un EDID mauvais.

Fix : Standardisez les versions de pilotes/firmware quand c’est possible. Utilisez un override EDID pour éliminer la variabilité quand la chaîne physique est fixée.

8) Symptom: “works after reboot” but fails again later

Cause racine : Condition de course au démarrage : EDID pas prêt quand sondé (KVM lent à activer DDC), puis le repli reste.

Fix : Mettez à jour le firmware/KVM. Utilisez un émulateur EDID. Dans certains cas, retarder le modeset ou forcer un mode via paramètre noyau stabilise le démarrage.

Listes de vérification / plan étape par étape

Étape par étape : réparer un hôte bloqué à 640×480 sans deviner

1. Identifiez le chemin d’affichage. Moniteur local ? KVM ? prolongateur ? adaptateur ? console distante BMC ? Notez-le ; ne comptez pas sur la mémoire.
2. Contournez la chaîne. Connectez‑vous directement à un moniteur connu‑bon avec un câble connu‑bon. Si cela corrige, arrêtez de blâmer l’OS.
3. Vérifiez l’état du connecteur dans sysfs. Confirmez « connected » et une liste de modes plausible.
4. Vérifiez la présence de l’EDID et décodez‑la. Confirmez le timing préféré et que la checksum est propre.
5. Recherche des logs noyau pour EDID/modeset. Cherchez échecs de lecture, problèmes de checksum, rejets de validation de mode, tempêtes de hotplug.
6. Testez un changement de mode en espace utilisateur (si vous avez des outils X11). Si ça réussit, concentrez‑vous sur pourquoi ça ne persiste pas.
7. Stabilisez la couche physique. Remplacez le câble. Retirez les adaptateurs. Préférez une liaison numérique bout en bout.
8. Si headless ou dépendant du KVM, utilisez une émulation EDID. Un EDID stable est souvent le correctif le plus propre, car il répare la négociation, pas seulement le symptôme.
9. Ensuite seulement envisagez de forcer un mode via des paramètres noyau ou de config. Documentez‑le. Facilitez le retour en arrière.
10. Testez la régression via reboot et événements hotplug. Ouvrez/fermez la console distante, basculez les ports KVM, cyclez l’alimentation du moniteur. Le bug se situe généralement dans les transitions.

Checklist : ce qu’il faut standardiser dans une flotte

• Un ou deux modèles approuvés de crash cart, incluant le KVM et son comportement EDID.
• Câbles connus‑bons (étiquetés) et une politique de retrait pour les câbles mystère.
• Profils d’émulation EDID approuvés pour les scénarios headless et console distante.
• Baseline firmware (BIOS/UEFI + BMC) et baseline pilote GPU pour les modèles serveurs.
• Paramètres noyau documentés et une politique : pas d’overrides video= « temporaires » sans ticket et date d’expiration.
• Chemin console série pour la sortie de récupération critique quand le graphique est peu fiable.

Checklist : quand forcer une résolution est acceptable (et quand ce n’est pas le cas)

• Acceptable : Environnement type kiosque dédié, moniteur fixe, chaîne stable, comportement de reboot testé.
• Acceptable : Serveur headless qui a besoin d’un framebuffer prévisible pour un outil spécifique ; override EDID documenté et versionné.
• Non acceptable : Environnement KVM mixte où la chaîne change ; forcer un mode peut créer des écrans noirs pendant les incidents.
• Non acceptable : Toute chose utilisée pour la récupération firmware sauf si vous avez testé la chaîne exacte et avez un plan de contournement.

FAQ

Pourquoi 640×480 apparaît‑t‑il même sur des systèmes HDMI/DisplayPort ?

Parce que le mode est un repli de compatibilité, pas une exigence du connecteur. Si l’EDID échoue ou si le hotplug se comporte étrangement, le logiciel choisit un plancher sûr.

Le « mode VGA » 640×480 est‑il la même chose qu’utiliser un câble VGA ?

Non. Vous pouvez afficher du 640×480 sur HDMI, DP, ou une console virtuelle. « VGA » signifie souvent « mode graphique compatible héritage », pas nécessairement le connecteur DE‑15.

Quelle est la manière la plus rapide de prouver que l’EDID est le problème ?

Comparez les blobs/hashes EDID entre une connexion directe et la chaîne problématique (KVM/adaptateur). Si l’EDID change ou disparaît, vous avez trouvé le coupable.

Pourquoi les commutateurs KVM causent‑ils cela si souvent ?

Beaucoup de KVM mettent en cache l’EDID ou présentent un EDID générique afin que les serveurs croient qu’un moniteur est toujours connecté. Cet EDID générique peut n’annoncer que des modes conservateurs.

Pourquoi ouvrir une console distante change parfois la résolution locale ?

Certains BMC déclenchent un hotplug ou une actualisation EDID lorsque la session de capture démarre. Si la lecture EDID échoue à ce moment, l’OS peut retomber à 640×480.

Dois‑je toujours forcer une résolution plus élevée via les paramètres noyau ?

Non. Forcer un mode peut transformer une situation « basse résolution mais utilisable » en « pas de vidéo du tout ». Réparez la chaîne ou stabilisez l’EDID d’abord ; forcez les modes seulement après avoir testé le retour en arrière.

Quelle résolution viser pour des opérations « sûres mais lisibles » ?

1024×768 et 1280×720 sont des compromis fréquents pour les UIs firmware et les consoles distantes. Elles sont largement supportées et généralement lisibles sans trop stresser les maillons faibles.

Comment gérer les serveurs headless qui ont besoin de graphiques pour les installateurs ou le KVM distant ?

Utilisez un émulateur EDID ou un override EDID validé afin que le système expose de manière cohérente une liste de modes raisonnable. Traitez‑le comme une pièce standard, pas comme un bricolage.

Pourquoi la liste de modes diffère entre sysfs, xrandr et ce que je vois à l’écran ?

Différentes couches rapportent différentes choses : la liste de modes DRM du noyau, les choix du compositeur en espace utilisateur, et ce que le visualiseur distant peut encoder. Identifiez quel « écran » vous utilisez réellement.

Est‑ce principalement un problème Linux ?

Non. Linux vous montre juste plus les tuyaux. Les mêmes problèmes de négociation existent dans tout OS parce que le point faible est souvent l’EDID/DDC dans des chaînes matérielles réelles.

Conclusion : étapes suivantes pour réellement réduire le risque

640×480 n’a pas survécu parce que les ingénieurs sont sentimentaux. Il a survécu parce que la compatibilité est une exigence business et une fonction de sécurité,
et parce que la négociation d’affichage est un système distribué caché à l’intérieur d’un câble.

Si vous voulez qu’il cesse de vous surprendre, faites trois choses :

1. Standardisez la chaîne physique (câbles, KVM, adaptateurs) de la même manière que vous standardisez alimentations et NICs.
2. Instrumentez la négociation avec des vérifications répétables : statut des connecteurs sysfs, décodage EDID, motifs de logs noyau et détection de hotplug.
3. Maintenez une trappe de secours ennuyeuse : câble direct + moniteur connu‑bon + émulateur EDID + console série pour quand le graphique devient du théâtre.

Faites cela, et 640×480 redevient ce qu’il devrait être : un repli que vous reconnaissez immédiatement, pas une machine à remonter le temps à laquelle vous n’aviez pas demandé de monter.