Ayer ejecuté apt upgrade y entró un kernel nuevo. Esta mañana dos de mis tres pantallas se quedaron en negro en cuanto inicié sesión en MATE. La BIOS, Plymouth y el login de LightDM se veían correctamente en todas. Cuando el escritorio cargaba, solo sobrevivía el panel interno del portátil. La AOC de 24" por HDMI y la MSI portátil de 16" por DVI se ponían negras.
El instinto es culpar al kernel. También es lo equivocado. Aquí cuento cómo lo averigüé en dieciocho minutos despachando cuatro agentes de IA en paralelo contra el portátil, sin tocar ni un fichero de configuración hasta tener un veredicto.
La configuración
Acer con AMD Picasso/Raven 2 (Vega), Ubuntu 22.04, escritorio MATE, gestor de ventanas marco. Tres pantallas conectadas: la interna eDP, una AOC de 24" por HDMI y una MSI portátil de 16" por DVI. AMDGPU-PRO DKMS como driver gráfico, kernel 5.15.0-176-generic. Acceso SSH al portátil ya autorizado desde CT-116, el contenedor Proxmox pequeño donde corro Claude Code.
El portátil está en 192.168.1.33. Yo sentado delante, solo con el panel interno, las dos externas en negro a mi derecha.
Cuatro agentes, una sola pasada
Le pedí a fer-pilot - mi copiloto general de Claude Code que registra automáticamente cada prompt y respuesta en una tarea de Odoo - que despachara un equipo de diagnóstico paralelo. El prompt nombró cuatro ámbitos:
- Agente E: inventario de kernel y módulos AMDGPU.
uname -r,dpkg -l 'linux-image-*',dkms status,lspci -nnk, el kernel anterior aún en /boot para fallback. - Agente F: auditoría del historial apt de las últimas 72 horas. ¿Qué paquetes cambiaron ayer realmente, había alguno del stack gráfico?
- Agente G: dmesg del último boot, comparación de
Xorg.0.logconXorg.0.log.old. Eventos HPD, fallos de atomic check, errores EDID, warnings de page flip. - Agente H: el estado en runtime. Output de
xrandrcon conectores y modos,~/.config/monitors.xml,~/.xsession-errors, lista de procesos del compositor.
Solo inspección, sin tocar nada hasta tener un veredicto coherente de los cuatro. Corrieron a la vez. Dieciocho minutos después los cuatro habían devuelto su informe más 15 ficheros de log adjuntos a la tarea.
Lo que encontraron los cuatro
El agente E confirmó que el kernel era 5.15.0-176-generic, que el previo 5.15.0-173 seguía intacto en /boot para fallback, que AMDGPU-PRO DKMS se había recompilado limpiamente para ambos kernels y que evdi (DisplayLink) estaba cargado.
El agente F hizo la observación más sorprendente: el kernel no cambió ayer. Había entrado el 17 de abril vía unattended-upgrade. El apt upgrade manual de ayer a las 02:56 solo tocó userspace: linux-firmware 3.41 -> 3.42, systemd/udev 3.19 -> 3.20, ubuntu-drivers-common, lcms2. Nada en mesa, libdrm, xserver-xorg-video-amdgpu, lightdm, gdm3 ni marco se modificó. El kernel llevaba once días en su sitio; simplemente no había reiniciado el portátil hasta anoche.
El dmesg del agente G estaba limpio para amdgpu. El conector nativo HDMI-A-0 reportaba el EDID de la AOC sin errores. Dos líneas (EE) viejas sobre drmmode_do_crtc_dpms cannot get last vblank counter existían tanto en Xorg.0.log como en Xorg.0.log.old, así que no eran una regresión nueva. El smoking gun del agente G era distinto: a las 12:13:42, exactamente cuando entré a MATE, evdi (la tarjeta virtual card2 de DisplayLink) hacía un power-cycle más tres eventos EDID-set.
El agente H cerró el círculo. xrandr -q reportaba HDMI-A-0 (AOC) y DVI-I-2-2 (MSI) como connected, con EDID válido y una lista completa de modos - pero sin CRTC ni geometría asignada. Solo eDP tenía posición 1920x1080+0+0. El servidor X veía las pantallas y leía sus EDIDs; nadie había llamado a xrandr --output ... --auto sobre ellas. La disposición guardada en ~/.config/monitors.xml referenciaba los conectores correctos pero nunca se aplicaba. mate-settings-daemon estaba corriendo, con su plugin xrandr activo, pero por algún motivo no estaba aplicando el layout al iniciar sesión.
El smoking gun
El diagnóstico se vuelve obvio cuando dejas de mirar al kernel y miras al timing del session start. El bump de systemd/udev 3.19 -> 3.20 cambia el orden en el que disparan los eventos hotplug durante el login de MATE. Lo que el plugin xrandr de mate-settings-daemon hacía en el momento justo, ya no lo hace, y el resultado es dos monitores visibles para el servidor X pero nunca asignados a un CRTC.
Esta fue la clase de incidencia que no tiene nada que ver con el driver, el firmware o el kernel. Es un problema de aplicación del layout.
El fix en dos ficheros
Le pedí al agente que aplicara el layout en vivo, conmigo mirando:
$ xrandr \
--output HDMI-A-0 --auto --primary --pos 0x0 \
--output eDP --auto --right-of HDMI-A-0 \
--output DVI-I-2-2 --auto --right-of eDP
La AOC volvió al instante, eDP se reposicionó, la MSI siguió. Para hacerlo persistente sin forzar un reboot, fer-pilot escribió dos ficheros:
~/.local/bin/fer-monitors.sh: el mismo comando xrandr con un sleep de 2 segundos para que corra después de que mate-settings-daemon termine, salida redirigida al journal víalogger -t fer-monitors.~/.config/autostart/fer-monitors.desktop: una entrada de autostart estándar de MATE apuntando al script, conX-MATE-Autostart-Phase=Applications.
Reversible con dos rm. Ningún fichero del sistema tocado. Compatible hacia delante con lo que sea que upstream acabe arreglando en mate-settings-daemon.
Tiempo total desde "las pantallas están en negro" hasta "las tres funcionan otra vez, y seguirán funcionando después de cada reboot": una hora, la mayoría revisando diffs con el agente.
Las lecciones
Tres ideas se me quedaron.
No te fíes del "cambió el kernel" hasta comprobarlo. Los agentes empezaron con la hipótesis de que el sospechoso era el kernel. El historial apt del agente F la voló en cinco minutos leyendo /var/log/apt/history.log. Once días con el mismo kernel, perfectamente bien, hasta que reinicié anoche.
Si un conector está "connected" con EDID y modos pero sin geometría, es autoconfig, no hardware. La señal eléctrica está bien; el servidor X incluso leyó el EDID. Nadie está llamando a --auto. Tocar el driver sería tirar tiempo.
Paralelo le gana a serial cuando los problemas son independientes. Kernel, historial apt, dmesg y estado runtime son cuatro ejes ortogonales. Consultarlos secuencialmente suma cuarenta minutos; consultarlos en paralelo cuesta lo que dura el agente más lento - dieciocho minutos. La síntesis es la mitad del valor del trabajo.
La historia entera, con los informes verbatim de los agentes, el slice de dmesg crudo, el diff entre Xorg.0.log y .old, y el screenshot post-fix, vive en el chatter de la tarea fer-pilot - auto-registrado turno a turno desde el momento en que pregunté "las pantallas están en negro".
29 de abril, 2026 - escrito desde el portátil con las tres pantallas otra vez en línea.