Por qué 640×480 se sintió eterno: estándares que no sueltan

El “modo eterno”: por qué 640×480 sigue ganando

640×480 no es solo una resolución. Es una tregua. Cuando una canalización de pantalla no puede ponerse de acuerdo sobre qué
es, qué puede hacer o qué puede hacer la otra parte, cae a algo que casi siempre funciona. En producción, “casi siempre funciona”
vence a “usualmente mayor resolución” cada vez.

Los estándares no mueren por ser antiguos. Mueren por ser inconvenientes. VGA nunca fue
inconveniente. Fue barato. Fue comprendido. Fue compatible con todo, desde firmware de era BIOS hasta conmutadores KVM empresariales
que han visto más mudanzas de racks que tu arquitecto senior. También tiene una propiedad que los equipos de operaciones valoran en privado: puedes obtener algo
en pantalla incluso cuando todo lo demás arde.

Las razones por las que 640×480 “gana” rara vez tienen que ver con preferencia. Tienen que ver con fallas de negociación:

• EDID no está disponible o no se confía en él, así que la GPU elige un modo seguro por defecto.
• Un KVM o adaptador miente (o “amablemente” sanitiza el EDID), por lo que nunca ves las capacidades reales del monitor.
• El firmware usa rutas GOP/VGA conservadoras durante el arranque, y lo notas al trabajar con consolas remotas.
• El kernel o el controlador cargan tarde, así que la consola temprana se queda en un modo mínimo hasta que userspace lo arregla.
• Las consolas virtuales y fuera de banda emulan supuestos antiguos para máxima compatibilidad.

Ese último punto es el que los ingenieros subestiman: la “pantalla” que estás viendo puede no ser
tu dispositivo de pantalla real. Podría ser el visor HTML5 de un BMC, un stream KVM vía IPMI,
una GPU virtual del hipervisor, o un aparato de captura que está más contento fingiendo que es 2004.

Primera verdad seca: 640×480 rara vez es el problema primario. Es el síntoma diagnóstico que dice
“el ajuste de modo falló en algún sitio”. Tu trabajo es encontrar dónde, luego decidir si arreglas la
negociación, la sobreescribes o la rodeas.

Un chiste corto, como recompensa: 640×480 es como ese compañero de trabajo que nunca aprende nuevas herramientas pero de alguna forma aún tiene acceso a producción.

Hechos e historia que explican el lío

Algunos hechos concretos—breves, poco románticos y útiles—explican por qué este estándar se niega a retirarse.
No son trivia; se mapean directamente a modos de fallo que verás en campo.

1. VGA de IBM (1987) popularizó 640×480 como una base gráfica común e interoperable. La industria copió esa base porque la interoperabilidad vende.
2. VESA se formó en 1989 para estandarizar modos y temporizaciones de pantalla, porque los vendedores enviaban señales “casi compatibles” que deprimían a los monitores.
3. VESA DDC y EDID (1990s) hicieron que los monitores se auto-describieran por I²C, para que los sistemas pudieran auto-seleccionar modos—hasta que el cable, el KVM o el adaptador rompen ese pequeño canal lateral.
4. Existen resoluciones de “modo seguro” porque un modo fuera de rango puede producir ninguna imagen, lo que en términos de ops es indistinguible de “el servidor está muerto”.
5. Servicios de video de la era BIOS mantuvieron vivas las suposiciones VGA en firmware y bootloaders; UEFI no borró esas expectativas de la noche a la mañana.
6. VGA analógico es tolerante con la calidad de señal comparado con algunos entrenamientos de enlace digital y expectativas de handshake; “tolerante” importa en cables largos y extensores baratos.
7. Conmutadores KVM empresariales históricamente priorizaron compatibilidad sobre pasar EDID perfecto. Algunos aún cachean un EDID y lo presentan a cada servidor.
8. Adaptadores HDMI-a-VGA son convertidores activos que deben inventar una señal analógica desde datos digitales; muchos incluyen soporte EDID mínimo y tablas de temporización cuestionables.
9. Gráficos de arranque temprano suelen ocurrir antes de que la pila completa de controladores esté cargada. Si el firmware de arranque elige 640×480, lo verás hasta que KMS/userspace vuelva a cambiar el modo.

El patrón: los estándares antiguos persisten cuando se convierten en la capa de interoperabilidad de último recurso.
Una vez que todo el ecosistema acuerda un “suelo”, ese suelo se convierte en una red de seguridad operativa.

La pila de estándares: VGA, VESA, EDID, DDC, GOP, KMS

VGA: la base que el firmware aún entiende

VGA es tanto una historia de conector como de señalización, y la gente las confunde constantemente.
“VGA” puede significar:

• RGB analógico sobre DE-15 (el conector azul), más señales de sincronización.
• Un conjunto de modos: temporizaciones canónicas como 640×480 a 60 Hz.
• Una capa de compatibilidad en firmware: “Siempre puedo dibujar texto y quizá píxeles”.

Por qué le gusta al firmware: es simple, bien entendida y no requiere negociación.
Por eso todavía ves comportamiento tipo VGA en el arranque temprano, incluso en sistemas que nunca han tenido un puerto DE-15.

Modos VESA y por qué la temporización importa

Una “resolución” está incompleta sin tasa de refresco y temporizaciones precisas. A los monitores les importan relojes de píxel,
anchos de sincronización, intervalos de blanking—esas cosas que no quieres pensar mientras depuras un incidente.
VESA creó fórmulas de temporización estandarizadas para que GPUs y monitores pudieran ponerse de acuerdo sobre qué significa eléctricamente “1024×768 @ 60”.

Cuando la negociación de modo falla, los sistemas suelen elegir una temporización establecida y conservadora: 640×480 @ 60.
Es menos probable que esté fuera de rango, menos probable que requiera relojes exóticos y más probable que esté presente en EDID
incluso cuando EDID está incompleto.

EDID y DDC: el “cablecito” que decide tu día

EDID (Extended Display Identification Data) es la auto-descripción del monitor: resoluciones soportadas,
temporización preferida, IDs de vendedor/producto y a veces bloques extra para audio o HDR.
Normalmente se transporta sobre DDC, un canal I²C enganchado al conector de pantalla.

Aquí está el punto operacional: EDID es una dependencia. Puede faltar, corromperse, cachearse o reemplazarse.
Y los sistemas que dependen de él—firmware, kernels, Xorg/Wayland, consolas remotas—cada uno tiene su propio
comportamiento de respaldo.

UEFI GOP vs VGA legado

El firmware moderno usa GOP (Graphics Output Protocol) para proporcionar un framebuffer a los bootloaders.
Si GOP se inicializa en una resolución baja (a veces basada en una lectura EDID simplista), tu salida de arranque
temprana se verá como una pieza de museo. Una vez que carga la pila gráfica del SO, puede reprogramar la pantalla,
pero solo si puede leer capacidades y aplicar un modo soportado.

Linux DRM/KMS: donde “debería funcionar” se encuentra con la realidad

DRM/KMS (Direct Rendering Manager / Kernel Mode Setting) significa que el kernel ajusta modos de pantalla temprano,
en lugar de esperar por userspace. Esto generalmente hace el arranque más suave y evita parpadeos de modo.
Pero también significa que una mala lectura de EDID puede bloquearte en un modo de respaldo antes de que userspace tenga oportunidad de arreglarlo.

Si recuerdas una cosa: cuando ves 640×480, pregunta “¿qué capa lo eligió?” Firmware? Kernel? Xorg/Wayland?
Consola remota? KVM? Adaptador? Eso es toda la investigación.

Una cita, porque la ingeniería de confiabilidad tiene manera de humillar suposiciones confiadas:
La esperanza no es una estrategia. — Gene Kranz

Dónde 640×480 aún aparece en operaciones reales

1) Carritos de rescate y el cajón del “KVM misterioso”

Conoces el cajón. El que tiene cables VGA sin etiquetas, un adaptador DisplayPort de un vendedor que ya no existe,
y un conmutador KVM que “todavía funciona bien”. Aquí es donde EDID se vuelve raro.

Muchos carritos incluyen un KVM que o bien cachea un EDID para siempre o presenta un EDID genérico a cada sistema conectado.
El EDID genérico a menudo incluye temporizaciones establecidas y conservadoras, y 640×480 es la más segura de las seguras.

2) Consolas remotas fuera de banda (BMC/IPMI/KVM-over-IP)

Los BMC a menudo implementan una canalización de pantalla virtual, capturando la salida de video y re-codificándola para visualización remota.
Algunos BMC manejan bien solo un subconjunto de modos. Otros manejan mal hotplug o EDID cuando abres la consola remota.

El resultado: tu servidor está renderizando felizmente a 1920×1080 localmente, pero la consola remota fuerza una re-detección,
y de repente el SO cae a 640×480 porque cree que el monitor desapareció.

3) Adaptadores HDMI/DP a VGA en salas de conferencias y laboratorios

Estos adaptadores son dispositivos activos. Tienen firmware. Pueden mentir. También pueden “solucionar” EDID anunciando
solo unos pocos modos para evitar llamadas de soporte. Si 640×480 aparece solo cuando el adaptador está en la cadena, cree en el patrón.

4) Sistemas sin monitor que fingen tener uno

Los servidores sin cabeza a veces necesitan un framebuffer para instaladores, para consolas iDRAC/iLO, o para entornos de cómputo GPU.
Sin un monitor físico, la GPU puede reportar “sin conectores” o puede sintetizar un modo mínimo.
Un dongle dummy que provea EDID puede arreglar esto al instante—siempre que proporcione un EDID sensato.

5) Virtualización y consolas anidadas

Una VM puede estar usando una GPU virtual con una lista de modos fija. Una consola del hipervisor puede forzar un modo de reserva.
O tu cliente RDP/VNC puede tener sus propias rarezas de negociación. Si tu “monitor” es un visor de software,
trátalo como un KVM: puede convertirse en el eslabón más débil.

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero

Esta es la lista que quiero en la pared cuando alguien avisa “consola atascada en 640×480” y la ventana de cambios se cierra.
El objetivo: identificar si el cuello de botella es enlace físico, EDID, firmware, controlador del kernel o userspace.

Primero: ¿La cadena de pantalla está mintiendo?

• Omite el KVM/extensor/adaptador. Conecta directamente con un cable a un monitor conocido y bueno.
• Cambia el cable y el puerto. Prefiere digital de extremo a extremo (DP/HDMI) si es posible.
• Si es consola remota: prueba con un monitor local; si local va bien, la “pantalla” es la canalización del BMC.

Segundo: ¿Se puede leer EDID y es sensato?

• En Linux, comprueba el estado del conector DRM y la presencia de EDID en sysfs.
• Busca “EDID checksum is invalid” o “failed to read EDID” en los logs del kernel.
• Si falta EDID: sospecha KVM, adaptador, cables largos o problemas con DDC/pines.

Tercero: ¿Qué capa fijó 640×480?

• ¿Solo en arranque temprano? Firmware/GOP lo eligió. El SO puede estar bien una vez cargado.
• ¿Permanece bajo en el inicio de sesión gráfico? Controlador del kernel o selección de modo en userspace.
• ¿Cambia al abrir consola remota? Hotplug/re-lectura EDID desencadenada por BMC/KVM.

Cuarto: Decide si arreglar la negociación o forzar un modo

• Si es transitorio o dependiente de la cadena: arregla la cadena (paso de EDID, mejor KVM, ruta DDC más corta).
• Si es headless por diseño: usa una anulación EDID correcta o un dongle dummy con EDID conocido y bueno.
• Si es un sistema puntual en un rack: forzar un modo puede ser aceptable, pero documéntalo como una mina terrestre.

Tareas prácticas: comandos, salidas y la decisión que tomas

A continuación hay tareas reales que puedes ejecutar en un host Linux para diagnosticar y arreglar la clase de problemas “atascado en 640×480”.
Cada tarea incluye: comando, qué significa la salida y la decisión que impulsa. Ejecútalas como root cuando sea necesario.

Task 1: Ver qué cree el kernel que hacen los conectores

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

Significado: Cada entrada card0-* es un conector. Si no ves el conector que esperas, no estás depurando “resolución”—estás depurando detección.

Decisión: Si falta el conector, enfócate en controlador/módulo/firmware y cableado físico, no en líneas de modo.

Task 2: Comprobar estado del conector (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

Significado: El kernel ve HDMI-A-1 como connected. Si dice disconnected mientras tienes pantalla, probablemente estás viendo una ruta remota/BMC.

Decisión: Si hace flap entre connected/disconnected, sospecha cable malo, comportamiento de hotplug del KVM o ahorro de energía en el monitor/KVM.

Task 3: Leer modos soportados desde sysfs

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

Significado: Esto es lo que DRM cree válido para ese conector. Si solo aparece 640×480, EDID está ausente/filtrado o el controlador recurrió a una lista interna mínima.

Decisión: Si la lista de modos es sospechosamente corta, pasa a la verificación de EDID y a los logs del kernel.

Task 4: Comprobar si existe EDID para el conector

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

Significado: Existe un blob EDID. Eso no garantiza que sea correcto, pero es buena señal.

Decisión: Si el archivo falta o su tamaño es 0, sospecha problemas en la ruta DDC/EDID (KVM, adaptador, cable).

Task 5: Decodificar EDID para confirmar modo preferido y sanidad

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

Significado: Tienes un EDID válido con una temporización preferida. Si el sistema aún elige 640×480, el problema probablemente sea política de selección de modo, limitaciones del controlador o un evento de hotplug posterior.

Decisión: Si EDID muestra solo modos bajos o decodifica con advertencias de checksum, reemplaza el enlace sospechoso (KVM/adaptador) u anula el EDID.

Task 6: Buscar en logs del kernel errores de EDID y modesetting

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

Significado: El log te dice si las lecturas de EDID tuvieron éxito y si la validación de modo falló.

Decisión: Si los modos son rechazados, comprueba limitaciones del controlador, restricciones de pixel clock y si el modo solicitado es realmente soportado por la cadena de conectores.

Task 7: Ver qué piensa Xorg/Wayland (ejemplo X11 con 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

Significado: X ve 1920×1080 como preferido pero actualmente está en 640×480. Eso normalmente significa una elección de política, un intento fallido de fijar el modo o una carrera con hotplug.

Decisión: Intenta cambiar al modo preferido; si falla, busca errores del controlador e inestabilidad de EDID.

Task 8: Forzar un modo temporalmente (X11) para validar capacidad

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

Significado: El cambio de modo funciona en userspace. Si luego vuelve a 640×480, algo está provocando una re-detección (hotplug del KVM, gestión de energía o apertura/cierre de consola remota).

Decisión: Si vuelve, céntrate en la estabilidad: deshabilita eventos de hotplug problemáticos, arregla el KVM o usa anulación EDID.

Task 9: Comprobar si estás en la ruta de consola virtual del BMC

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

Significado: Identifica la plataforma del servidor que probablemente tenga un BMC. No es prueba, pero es una pista de que podrías estar viendo vía KVM-over-IP con sus propias restricciones.

Decisión: Si la consola remota se comporta diferente a la local, trata al BMC como parte de la cadena de pantalla y prueba ambas rutas.

Task 10: Confirmar qué controlador está en uso y si KMS está activo

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

Significado: Confirma el controlador del kernel. Si ves un controlador genérico (como vesa en algunos contextos) puedes estar atrapado en una ruta de reserva que limita los modos.

Decisión: Si el controlador correcto no está cargado, corrige eso primero; ningún xrandr compensará un módulo de kernel incorrecto.

Task 11: Inspeccionar estado de depuración DRM para pistas de validación de modo

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

Significado: La depuración específica del controlador puede mostrar estado de enlace y listas de modos que el controlador está dispuesto a usar.

Decisión: Si link-status es malo o faltan modos aquí pero aparecen en otros sitios, tienes un problema de controlador/entrenamiento de enlace, no de entorno de escritorio.

Task 12: Comprobar si un parámetro de arranque del kernel está forzando baja resolución

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

Significado: Alguien forzó el modo vía video=. Esto es común tras “arreglos temporales” que se volvieron permanentes.

Decisión: Elimina o ajusta el parámetro si la cadena de hardware ahora soporta un modo mejor; de lo contrario documenta por qué existe y de qué depende.

Task 13: Forzar un modo conocido bueno temprano con DRM (prueba temporal)

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

Significado: Estás instruyendo al modesetting del kernel para elegir un modo específico en ese conector.

Decisión: Usa esto como prueba controlada. Si funciona, la negociación era el problema. Si falla (pantalla en negro), revierte y arregla EDID/cableado en lugar de forzar bruscamente.

Task 14: Capturar EDID a un archivo para comparar entre 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

Significado: El hash te permite detectar cuando EDID cambia entre “monitor directo” y “a través de KVM”, que a menudo es todo el caso.

Decisión: Si el hash de EDID cambia según la cadena, deja de discutir con el software y reemplaza/actualiza la cadena o configura la emulación de EDID correctamente.

Task 15: Validar si el problema está solo en la consola de texto

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

Significado: Tu consola framebuffer está configurada en 640×480. La sesión gráfica aún podría cambiar más tarde, pero si no lo hace, esto indica que KMS/ajuste de modo temprano está fijado bajo.

Decisión: Si necesitas consolas legibles durante la respuesta a incidentes, ajusta un modo temprano mejor o cambia a consola serie donde corresponda.

Task 16: Detectar tormentas de hotplug (a menudo causadas por 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

Significado: El sistema está perdiendo EDID durante hotplug. Eso es comportamiento clásico de KVM (o un adaptador defectuoso) y explica “se reinicia a 640×480 aleatoriamente.”

Decisión: Arregla la cadena física o usa un emulador/dongle EDID; no sigas peleando con la configuración del escritorio.

Segundo chiste corto, luego volvemos al trabajo: EDID significa “Eventualmente Muestra en 640×480” cuando pones un KVM barato en medio.

Tres mini-historias corporativas (anonimizadas, plausibles, técnicamente correctas)

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa mediana desplegó un nuevo kit “estándar” de carrito de rescate en varias salas de datos. El kit parecía limpio:
un cajón 1U, un monitor, un KVM compacto y una bolsa de adaptadores para cubrir cualquier cosa. Pasó la prueba de laboratorio. Pasó un
piloto. Luego se enfrentó a la realidad: una mezcla de proveedores de GPU, versiones de firmware y racks con extensores KVM ya instalados.

La suposición errónea fue simple: “Si el monitor funciona directamente, funcionará a través del KVM.” El nuevo KVM cacheó el EDID
del primer monitor que vio durante la configuración, luego sirvió ese EDID a todos los servidores para siempre. En un pasillo, el primer monitor
que se conectó fue una unidad antigua que anunciaba una lista de modos mínima. El KVM clonó fielmente esa mediocridad en
todo lo downstream.

El incidente ocurrió durante una ventana de mantenimiento cuando los ingenieros necesitaban acceso al BIOS en un lote de servidores. La mitad de las máquinas
mostraron solo 640×480, y la UI del BIOS se convirtió en un carrusel en movimiento. Los ingenieros malinterpretaron elementos del menú, activaron el modo SATA incorrecto
en algunas cajas y crearon una cascada de fallos de arranque evitable. No se rompió nada exótico. Los humanos lo rompieron, asistidos por una IU de baja resolución
y un calendario apretado.

La solución no fue “establecer una resolución más alta.” La solución fue operativa: estandarizar la cadena del carrito, bloquear el EDID del KVM a un
perfil conocido y bueno, y documentar el proceso para resetear caches EDID al cambiar monitores. También: dejar de mezclar extensores y KVMs
salvo que puedas probar paso de EDID de extremo a extremo. Si tu cadena de pantalla mantiene estado, trátala como una dependencia de producción.

Mini-historia 2: La optimización que salió mal

Otra organización intentó “optimizar” la resolución de problemas remotos incentivando el uso de consolas remotas BMC en lugar de carritos físicos.
El plan era razonable: menos manos en la sala de datos, respuesta más rápida, mejor registro. Alguien notó que a resoluciones más altas,
el rendimiento de la consola remota era lento. Así que establecieron los gráficos de arranque de los servidores en un modo más bajo para hacer el stream remoto
más “ligero” y “ágil”.

Hizo que el stream fuera más ligero. También dejó a los ingenieros a ciegas. Varias tareas de mantenimiento críticas dependían de leer entradas de bootloader de ancho completo
y salidas de kernel panic. A 640×480, las líneas se envolvían de forma impredecible. La gente empezó a copiar parámetros equivocados.
Algunas máquinas se arrancaron con ajustes de dispositivo root incorrectos. El incidente no fue dramático; fue peor. Fue una fuga lenta de
tiempo, errores y reinicios innecesarios en varias rotaciones on-call.

El rebatimiento fue sutil: la “optimización” mejoró una métrica (respuesta de consola remota) mientras degradaba el objetivo real
(recuperación exitosa). La organización había optimizado por ancho de banda y CPU en la canalización BMC, no por la corrección humana bajo estrés.
Una consola legible es una característica de fiabilidad.

Revirtieron el cambio e implementaron uno mejor: mantener una resolución legible (a menudo 1024×768 o 1280×1024) y reducir la codificación
del BMC mediante ajustes que no destruyan la usabilidad. También movieron rutas críticas de recuperación a serial-over-LAN para salida de texto, que no es elegante pero es predecible y scriptable.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros tenía una regla que sonaba dolorosamente conservadora: cada rack debía tener al menos un cable digital directo conocido y bueno
(sin adaptadores), y cada carrito de rescate debía llevar un pequeño dongle emulador EDID que anuncie una lista de modos verificada.
Nadie lo amaba. Compras preguntaban por qué compraban “gadgets raros”. Los ingenieros bromeaban. Luego se pagó a sí mismo.

Durante un evento de energía en la instalación, varios KVMs se reiniciaron en estados por defecto y empezaron a presentar EDID genérico a hosts downstream.
Un subconjunto de servidores cayó a 640×480 durante el arranque temprano. El equipo on-call necesitaba acceder a ajustes de firmware en algunas cajas
que habían arrancado en modo RAID degradado. La baja resolución hizo que la IU del firmware fuera apenas navegable a través de la cadena KVM.

En lugar de depurar en el momento, ejecutaron la práctica aburrida: saltaron el KVM, conectaron el cable conocido y bueno, y si el servidor era headless o caprichoso, insertaron el emulador EDID.
La lista de modos se estabilizó. La IU del firmware se volvió legible. El equipo tomó decisiones correctas rápidamente.

El “salvamento” no fue ingeniería mágica. Fue una salida planificada. En producción, lo aburrido es un cumplido. Todo aquello que
convierte de forma fiable “extraño desconocido” en “línea base conocida” vale la pena llevarlo, documentarlo y practicarlo.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: solo 640×480 está disponible en la lista de modos

Causa raíz: EDID no legible (DDC roto), o KVM/adaptador presenta un EDID mínimo.

Solución: Omite la cadena; confirma la presencia de EDID en /sys/class/drm/*/edid. Reemplaza cable/KVM/adaptador o usa emulador/anulación EDID.

2) Síntoma: existe modo preferido, pero el sistema arranca en 640×480 y se queda ahí

Causa raíz: Parámetros de arranque del kernel forzando modo bajo; userspace no realiza el modeset; controlador atascado en fallback.

Solución: Comprueba /proc/cmdline. Elimina video=...:640x480 o establece el modo deseado. Asegura que el controlador GPU correcto esté cargado.

3) Síntoma: la resolución está bien localmente, pero la consola remota provoca caída a 640×480

Causa raíz: BMC/KVM-over-IP dispara hotplug o re-lectura de EDID; la lectura de EDID falla de forma intermitente.

Solución: Busca eventos de hotplug en journalctl -k. Estabiliza EDID con emulador o configura el KVM para mantener EDID afirmado.

4) Síntoma: la pantalla se queda en negro al forzar 1080p, pero 640×480 funciona

Causa raíz: La cadena no puede manejar pixel clock o temporización (extensor barato, recorrido VGA largo, convertidor débil).

Solución: Elige un modo intermedio (1024×768 o 1280×720) y reemplaza el eslabón débil. No fuerces un modo fuera de especificación para la cadena.

5) Síntoma: cambios aleatorios entre 640×480 y resolución mayor

Causa raíz: Tormentas de hotplug o sueño del monitor provocando pérdida transitoria de EDID; pines DDC del cable defectuosos.

Solución: Reemplaza el cable primero. Luego elimina KVM/extensor de la cadena. Confirma estabilidad comparando hashes de EDID a lo largo del tiempo.

6) Síntoma: solo la consola de texto está en 640×480, la sesión gráfica está bien

Causa raíz: Consola de arranque atascada con framebuffer seleccionado por firmware; userspace realiza modesets correctamente más tarde.

Solución: Si te importa ver salida legible en el arranque temprano, configura video= del kernel a un modo sensato o configura la resolución GOP del firmware cuando esté disponible.

7) Síntoma: diferentes servidores en el mismo monitor/KVM se comportan distinto

Causa raíz: Diferentes controladores GPU validan modos de manera distinta; versiones de firmware leen EDID de forma diferente; algunos controladores son más estrictos con EDID malo.

Solución: Estandariza versiones de controlador/firmware cuando sea posible. Usa anulación EDID para eliminar variabilidad cuando la cadena física esté fija.

8) Síntoma: “funciona tras reiniciar” pero falla de nuevo más tarde

Causa raíz: Condición de carrera durante el arranque: EDID no está listo cuando se prueba (KVM lento al afirmar DDC), luego el fallback queda fijado.

Solución: Actualiza firmware/KVM. Usa emulador EDID. En algunos casos, retrasar el modeset o forzar un modo vía parámetro del kernel estabiliza el arranque.

Listas de verificación / plan paso a paso

Paso a paso: arreglar un host atascado en 640×480 sin adivinar

1. Identifica la ruta de pantalla. Monitor local? KVM? extensor? adaptador? consola remota BMC? Anótalo; no confíes en la memoria.
2. Omite la cadena. Conecta directamente a un monitor conocido y bueno con un cable conocido y bueno. Si eso lo arregla, deja de culpar al SO.
3. Comprueba el estado del conector en sysfs. Confirma “connected” y una lista de modos plausible.
4. Verifica presencia y decodifica EDID. Confirma temporización preferida y que el checksum esté limpio.
5. Busca en logs del kernel errores de EDID/modeset. Busca fallos de lectura, problemas de checksum, rechazos de validación de modo, tormentas de hotplug.
6. Prueba un cambio de modo en userspace (si tienes herramientas X11). Si tiene éxito, céntrate en por qué no persiste.
7. Estabiliza la capa física. Reemplaza cable. Quita adaptadores. Prefiere digital de extremo a extremo.
8. Si es headless o dependiente de KVM, usa emulación EDID. Un EDID estable suele ser la “solución” más limpia, porque arregla la negociación, no el síntoma.
9. Sólo entonces considera forzar un modo vía parámetros del kernel o configuración. Documéntalo. Facilita la reversión.
10. Prueba regresión mediante reinicio y eventos hotplug. Abre/cierra consola remota, cambia puertos KVM, alimenta el monitor. El bug suele estar en las transiciones.

Lista de verificación: qué estandarizar en una flota

• Uno o dos modelos aprobados de carrito de rescate, incluyendo el KVM y su comportamiento EDID.
• Cables conocidos buenos (etiquetados) y una política de retirada para cables misteriosos.
• Perfiles EDID emulador aprobados para escenarios headless y de consola remota.
• Línea base de firmware (BIOS/UEFI + BMC) y línea base de controladores GPU para modelos de servidor.
• Parámetros del kernel documentados y una política: no hay overrides “temporales” video= sin ticket y fecha de expiración.
• Ruta de consola serie para salida crítica de recuperación cuando los gráficos son poco fiables.

Lista de verificación: cuándo es aceptable forzar resolución (y cuándo no)

• Aceptable: Entorno kiosk dedicado, monitor fijo, cadena estable, comportamiento de reinicio probado.
• Aceptable: Servidor headless que necesita un framebuffer predecible para una herramienta específica; la anulación EDID está documentada y versionada.
• No aceptable: Entorno KVM mixto donde la cadena cambia; forzar un modo puede crear pantallas en negro durante incidentes.
• No aceptable: Cualquier cosa usada para recuperación de firmware a menos que hayas probado la cadena exacta y tengas un plan de bypass.

Preguntas frecuentes

¿Por qué aparece 640×480 incluso en sistemas HDMI/DisplayPort?

Porque el modo es un fallback de compatibilidad, no un requisito del conector. Si EDID falla o hotplug se vuelve raro, el software elige una base segura.

¿El “modo VGA” 640×480 es lo mismo que usar un cable VGA?

No. Puedes ejecutar 640×480 sobre HDMI, DP o una consola virtual. “VGA” muchas veces significa “modo gráfico compatible con legado”, no el conector DE-15.

¿Cuál es la forma más rápida de demostrar que EDID es el problema?

Compara blobs/hashes EDID entre una conexión directa y la cadena problemática (KVM/adaptador). Si el EDID cambia o desaparece, encontraste al culpable.

¿Por qué los conmutadores KVM causan esto tan a menudo?

Muchos KVMs o bien cachean EDID o presentan un EDID genérico para que los servidores crean que un monitor está siempre conectado. Ese EDID genérico puede anunciar solo modos conservadores.

¿Por qué abrir una consola remota a veces cambia la resolución local?

Algunos BMCs disparan un hotplug o refresco de EDID cuando la sesión de captura se inicia. Si las lecturas de EDID fallan en ese momento, el SO puede retroceder a 640×480.

¿Debo siempre forzar una resolución más alta con parámetros del kernel?

No. Forzar un modo puede convertir una situación “baja resolución pero usable” en “sin video en absoluto.” Arregla la cadena o estabiliza EDID primero; fuerza modos solo si has probado la reversión.

¿Qué resolución debería elegir para operaciones “seguras pero legibles”?

1024×768 y 1280×720 son puntos comunes para UIs de firmware y consolas remotas. Son ampliamente soportadas y generalmente legibles sin exigir demasiado a enlaces débiles.

¿Cómo manejo servidores headless que necesitan gráficos para instaladores o KVM remota?

Usa un emulador EDID o una anulación EDID validada para que el sistema exponga consistentemente una lista de modos sensata. Trátalo como una parte estándar, no como un parche.

¿Por qué la lista de modos difiere entre sysfs, xrandr y lo que veo en pantalla?

Diferentes capas reportan cosas diferentes: lista de modos DRM del kernel, elecciones del compositor en userspace y lo que el visor remoto puede codificar. Identifica qué “pantalla” estás usando realmente.

¿Esto es mayormente un problema de Linux?

No. Linux solo te muestra más de la tubería. Las mismas cuestiones de negociación existen en cualquier SO porque el punto débil suele ser EDID/DDC a través de cadenas de hardware del mundo real.

Conclusión: siguientes pasos que realmente reducen el riesgo

640×480 no sobrevivió porque los ingenieros sean sentimentales. Sobrevivió porque la compatibilidad es un requisito de negocio y una función de seguridad,
y porque la negociación de pantalla es un sistema distribuido escondido dentro de un cable.

Si quieres que deje de sorprenderte, haz tres cosas:

1. Estandariza la cadena física (cables, KVMs, adaptadores) igual que estandarizas fuentes de alimentación y NICs.
2. Instrumenta la negociación con comprobaciones repetibles: estado de conectores en sysfs, decodificación EDID, patrones en logs del kernel y detección de hotplug.
3. Mantén una salida aburrida: cable directo + monitor conocido y bueno + emulador EDID conocido + consola serie para cuando los gráficos se vuelven teatro.

Haz eso, y 640×480 se convertirá en lo que debe ser: un fallback que reconoces de inmediato, no una máquina del tiempo a la que no querías subir.