Fix #819: preserve user-applied monitor config across DRM hotplug

[RedDawe]

Fixes #819.

Background

When a user explicitly disables an external monitor (via xrandr --output X --off, Super+P, or the Cinnamon Display GUI), Muffin re-enables it on the next DRM hotplug event — most commonly triggered by the monitor itself performing an auto input-scan and re-toggling its link state. The user's intent is silently overridden until they re-disable, often within seconds.

Root cause

The user's most recent intent lives in MetaMonitorConfigManager::current_config, which is updated on every successful apply_monitors_config() (including METHOD_TEMPORARY applies, which xrandr / Super+P / D-Bus go through). On hotplug, meta_monitor_manager_on_hotplug() calls meta_monitor_manager_ensure_configured(), whose fallback chain is stored → suggested → previous → linear → fallback. The currently-applied config is never consulted, so any state that hasn't also been written to cinnamon-monitors.xml is lost — create_suggested() rebuilds a fresh layout that re-enables every detected output.

This affects the common case where the user applies a temporary off (no GUI save), but also the should_use_stored_config() branch (hotplug_mode_update) where stored config is bypassed entirely.

Fix

src/backends/meta-monitor-manager.c: insert a current_config-preferring branch at the top of ensure_configured(). If a config has already been applied this session and is still complete for the detected monitor set (is_config_complete checks the EDID-derived monitor-spec key), re-apply it. Skipped during in_init so the on-disk stored config still wins on session start. Genuine plug/unplug changes the spec key, so is_config_complete returns false and the existing fallback chain runs as before.

src/backends/meta-monitor-config-manager.c: guard set_current() against the no-op current == config self-set. Without this, every hotplug pushes a duplicate of the current config onto the 3-slot history queue, evicting the genuine previous configs that exist for things like pop_previous undo.

Test

src/tests/monitor-unit-tests.c: regression test that (1) builds a config with the second monitor disabled, (2) marks it current as apply_monitors_config() would after a TEMPORARY apply, (3) triggers a hotplug with the same monitor topology. Asserts the disabled state is preserved across the hotplug. Without the fix this test fails because ensure_configured() falls through to create_suggested().

Confirmation on real hardware (HP Omen 27q via amdgpu, or any monitor with auto input-scan behavior) would be appreciated from anyone with the matching setup.

[RedDawe]

While looking into this I noticed muffin's ensure_configured() has diverged from upstream mutter, and that divergence is the actual root cause of #819.

Mutter consults the current (live, not-yet-persisted) config before falling back, trying configs in this order:

stored → [current, previous] → suggested → linear → fallback

Muffin currently does:

stored → suggested → previous → linear → fallback

So muffin never re-applies current_config, and it reaches create_suggested (which re-enables every output) before it ever looks at previous. That's why upstream isn't affected.

There are two ways to fix this, happy to go with whichever you prefer:

1. Minimal (what this PR does now): an early check at the top of ensure_configured() that re-applies the current config when the monitor topology is unchanged, before the existing fallback chain runs.

2. Align with mutter: rework the fallback to build an existing_configs list from current + previous and try those ahead of create_suggested, matching upstream's structure. Bigger diff and it reorders the fallback chain, but it reduces divergence and should ease future rebases.

The regression test applies either way. I have option 2 prepared on a branch and can push it as an alternative commit for comparison if that's useful.