When a fake (dummy) HDMI plug shows up as a phantom third monitor and wrecks your layout

Environment: Kubuntu 26.04 LTS · KDE Plasma 6 (X11 session) · 2560×1440 dual monitors + an EDID dummy HDMI plug

TL;DR

If an EDID-emulating dummy HDMI plug shows up as a phantom monitor and wrecks your layout, don't try to fold it into your screen space with Duplicate/Extend — set it to Disable. The port stays "connected" (so the GPU doesn't go headless) while dropping out of the desktop area.

Background: why the dummy HDMI was plugged in

Connecting to this PC's Windows via Samsung DeX with all monitors physically off caused the GPU to decide there was "nothing to output," making the screen stutter. To prevent that, a dummy HDMI plug (a little dongle that pretends to be a monitor via EDID) was left in a port — to keep the GPU thinking something's always attached.

On Windows, setting that dummy as a "Duplicate" of the second monitor solved it cleanly, and it held up even through powering all the displays off and on. The dummy carried over to Linux still plugged in, and the user first tried the same "Duplicate" that had worked on Windows — which is where this broke.

The symptom: xrandr reports three monitors

There are two real monitors, but the xrandr output the user sent under X11 showed three.

DP-0   connected primary 2560x1440+0+0
DP-4   connected 2560x1440+2560+0
HDMI-1 connected 3840x2160+2560+0   ← the dummy plug, overlapping DP-4 exactly

Trying to set this to "Duplicate" matching the second monitor kept warping the second monitor's resolution, pushing part of the picture into a physically invisible region.

Root cause: the dummy's EDID doesn't support the real monitor's resolution

The dummy plug's advertised resolution list looked like this:

3840x2160, 4096x2160, 1920x1080, 1440x900, 1280x1024, 1280x720, ...

It jumps straight from 1080p to 4K, and the real monitors' native 2560×1440 isn't in the list at all. "Duplicate" requires both outputs to share a resolution, so with the dummy not supporting 1440p, the system stretched the canvas to a larger resolution (4K), and since the real panels are physically 1440p, the extra area fell off screen.

The misdiagnosis: "Extend mode will fix it"

To dodge the resolution conflict I reached for Extend mode, but that creates a different problem — Extend folds the dummy screen into usable desktop space, so windows or the cursor crossing onto that "nobody's looking" screen can genuinely vanish somewhere invisible.

The fix: Disable

The dummy plug's actual purpose (keeping the GPU from going headless) is a lower-level thing, separate from the layout (Duplicate or Extend) — the HDMI port just needs to signal "I'm connected" via EDID; nothing needs to actually render on top of it.

Setting that output to Disable in System Settings → Display leaves the port "connected" (the GPU still sees something attached) while dropping it completely out of the desktop space — no windows can hide there. (Whether this state still reproduces the DeX anti-disconnect effect the dummy provided on Windows is untested — with no remote session needed right now, I deferred that test.)

Twist 1: even "Disable" doesn't survive a monitor power cycle

That afternoon, powering the two real monitors off and on promoted the dummy HDMI-1 back to primary, alone at 4K (xrandr showed DP-0/DP-4 as connected with no active mode, and only HDMI-1 as connected primary). The morning's "Disable" hadn't survived the power cycle.

Checking ~/.config/kscreen/, the folder didn't exist — so on this system KDE isn't saving/restoring layouts as "profiles"; it seems to re-decide from scratch every time the output topology changes (including a monitor going into standby). If the real monitors briefly have "no active mode," the always-alive dummy is the only output that can produce a mode, so everything falls onto it.

Ad-hoc manual recovery was:

xrandr --output HDMI-1 --off \
  --output DP-0 --primary --mode 2560x1440 --pos 0x0 \
  --output DP-4 --mode 2560x1440 --pos 2560x0

Twist 2: xrandr fixed it, but the wallpaper and panel vanished

The xrandr above set the outputs right (xrandr --query was perfect), yet the screen went to a black wallpaper with the whole bottom panel gone. The cause was elsewhere — raw xrandr only changes the X11 level; KDE's own display management (KScreen) doesn't know about it. So X11 was correct while the KDE-side screen info that plasmashell (which draws the wallpaper and panel) relies on was still out of sync, looping requesting unexisting screen available rect -1.

Restarting plasmashell didn't help either. I first asked the user to kill and relaunch it with kquitapp6 + manual nohup, but it turns out plasmashell on this distro is managed as a systemd --user service (plasma-plasmashell.service), so a manually launched process becomes an orphan outside systemd's tracking. Even a proper systemctl --user restart plasma-plasmashell.service didn't fix it — because the problem was a layer below plasmashell, in KScreen.

What actually fixed it: dragging the screen arrangement manually once in System Settings → Display (swapping left/right positions twice) finally got KDE to re-read the current state and recover.

Takeaways / checklist

An EDID-emulating dummy plug is safest kept as "connected but not part of the layout" — don't try to fold it in with Duplicate/Extend.
When diagnosing multi-monitor oddities, dump the full xrandr output once to check for "an output I didn't know about."
On this KDE setup, change layouts with kscreen-doctor (KDE's own display CLI) or System Settings rather than raw xrandr — xrandr only fixes X11 and leaves KDE's higher-level state out of sync.
On a system with no ~/.config/kscreen/, "Disable" can come undone on every power cycle — if it recurs, script the manual xrandr command, or just unplug the dummy until you actually need it.

This came out of the same multi-monitor cleanup, after switching to X11 for the NVIDIA+Wayland cursor bug.