Three monitors, four agents, one apt upgrade

Yesterday I ran apt upgrade and a new kernel landed. This morning two of my three monitors went dark the moment I logged into MATE. BIOS, Plymouth, and the LightDM login screen showed up on every panel as usual. The instant the desktop loaded, only the laptop's internal panel survived. The 24" AOC on HDMI and the 16" MSI on DVI both went black.

The instinctive move is to blame the kernel. It is also the wrong one. Here is how I figured that out in eighteen minutes by dispatching four AI agents in parallel against the laptop, without touching a single configuration file until I had a verdict.

The setup

Acer with AMD Picasso/Raven 2 (Vega), Ubuntu 22.04, MATE desktop, marco window manager. Three displays plugged in: the internal eDP, an HDMI to a 24" AOC, and a DVI to a 16" MSI portable. AMDGPU-PRO DKMS as the graphics driver, kernel 5.15.0-176-generic. SSH access to the laptop already trusted from CT-116, the small Proxmox container where I run Claude Code.

The laptop is at 192.168.1.33. I was sitting in front of it, internal panel only, the two black externals to my right.

Four agents, one shot

I asked fer-pilot - my general-purpose Claude Code copilot that auto-logs every prompt and response into an Odoo task - to dispatch a parallel diagnostic team. The prompt named four scopes:

• Agent E: kernel and AMDGPU module inventory. uname -r, dpkg -l 'linux-image-*', dkms status, lspci -nnk, the previous kernel still in /boot for fallback.
• Agent F: apt history audit for the last 72 hours. Which packages actually changed yesterday, and were any of them graphics-stack?
• Agent G: dmesg from the current boot, plus Xorg.0.log compared with Xorg.0.log.old. Looking for HPD events, atomic check failures, EDID errors, page-flip warnings.
• Agent H: the runtime state. xrandr output for connectors and modes, ~/.config/monitors.xml, ~/.xsession-errors, compositor process list.

Read-only inspection only. No fixes until I had a coherent verdict from all four. They ran concurrently. Eighteen minutes later all four had returned reports plus 15 raw log files attached to the task.

What the four found

Agent E confirmed the kernel was 5.15.0-176-generic, the previous 5.15.0-173 was still intact in /boot for a clean fallback, AMDGPU-PRO DKMS had rebuilt cleanly for both kernels, evdi (DisplayLink) was loaded.

Agent F made the most surprising call: the kernel did not change yesterday. It had landed on April 17th via unattended-upgrade. Yesterday's manual apt upgrade at 02:56 only touched userspace: linux-firmware 3.41 -> 3.42, systemd/udev 3.19 -> 3.20, ubuntu-drivers-common, lcms2. Nothing in mesa, libdrm, xserver-xorg-video-amdgpu, lightdm, gdm3, or marco was modified. The kernel had been in place for eleven days; I had simply not rebooted the laptop until last night.

Agent G's dmesg was clean for amdgpu. The native HDMI-A-0 connector reported the AOC's EDID without errors. Two old (EE) lines about drmmode_do_crtc_dpms cannot get last vblank counter existed in both Xorg.0.log and Xorg.0.log.old, so they were not a new regression. The smoking gun in Agent G's report was different: at 12:13:42, exactly when I logged into MATE, evdi (DisplayLink virtual card2) did a power-cycle plus three EDID-set events.

Agent H closed the loop. xrandr -q reported HDMI-A-0 (AOC) and DVI-I-2-2 (MSI) as connected, with valid EDID and a full mode list - but with no CRTC and no geometry assigned. Only eDP had position 1920x1080+0+0. The X server saw the displays and read their EDIDs; nobody had ever called xrandr --output ... --auto on them. The saved layout in ~/.config/monitors.xml referenced the right connectors but was never applied. mate-settings-daemon was running, with its xrandr plugin enabled, but for some reason it was not driving the layout at session start.

The smoking gun

The diagnosis becomes obvious when you stop looking at the kernel and start looking at session-start timing. The systemd/udev 3.19 -> 3.20 bump shifts the order in which hot-plug events fire during MATE login. Whatever mate-settings-daemon's xrandr plugin used to do at the right moment, it now misses, and the result is two monitors visible to the X server but never assigned a CRTC.

This was the kind of fix that has nothing to do with the driver, the firmware, or the kernel. It is a layout-application problem.

The fix in two files

I asked the agent to apply the layout live, with me watching:

$ 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

The AOC came back instantly, eDP repositioned, the MSI followed. To make it persistent without forcing a reboot, fer-pilot wrote two files:

• ~/.local/bin/fer-monitors.sh: the same xrandr command with a 2-second sleep so it runs after mate-settings-daemon settles, output piped to the journal via logger -t fer-monitors.
• ~/.config/autostart/fer-monitors.desktop: a standard MATE autostart entry pointing at the script, with X-MATE-Autostart-Phase=Applications.

Reversible with two rm commands. No system files touched. Forward-compatible with whatever upstream eventually fixes in mate-settings-daemon.

Total elapsed time from "the screens are black" to "all three are working again, and they will work after every reboot": about an hour, most of which was discussion and diff review with the agent.

The lessons

Three takeaways stayed with me.

Don't trust "kernel changed" until you check. The agents started with the assumption that the kernel was the suspect. Agent F's apt history blew that hypothesis up in five minutes by reading /var/log/apt/history.log. Eleven days of the same kernel, perfectly fine, until I rebooted last night.

If a connector is "connected" with EDID and modes but no geometry, it is autoconfig, not hardware. The display electrical signal is fine; the X server even read the EDID. Nobody is calling --auto. Driver work would be wasted.

Parallel beats serial when problems are independent. Kernel, apt history, dmesg, and runtime state are four orthogonal axes. Querying them sequentially adds up to forty minutes; querying them in parallel takes the longest single agent - eighteen minutes. The synthesis is half the value of the work.

The whole story, with the verbatim agent reports, the raw dmesg slice, the diff between Xorg.0.log and .old, and the post-fix screenshot, lives in the fer-pilot task chatter - auto-logged turn by turn from the moment I asked, "the screens are black".

Apr 29, 2026 - written from the laptop with the three monitors back in line.