fix(docking): the undock keyword is inert, not raced; escalate to reload
All checks were successful
Check / eval (push) Successful in 3m10s

Round 7 FAILED: 5-6 consecutive unplugs on the dev box, the panel never came
back. Round 6's retry could not have worked, because round 6's diagnosis was
wrong — and so was the "phantom re-add" theory I brought to this session.

With ZERO enabled outputs — panel disabled by the dock, external gone —
Hyprland 0.55.4 accepts `hyprctl keyword monitor eDP-1,preferred,auto,1`,
prints `ok`, exits 0, and never flushes it: the rule waits for a DRM event
that is not coming. It is inert, not raced. Retrying it 25x/poll for 6 polls
bought 30s of black screen and nothing else.

What made this survive two rounds is worth more than the fix: every
`transition=undock result=ok` in the round-6 journal was Bernardo plugging
the cable back in because the screen was black. His hotplug flushed the
queued rule and the next poll took the credit. Success was indistinguishable
from the user working around the failure, so the logs confirmed whichever
story we brought to them. Ten minutes of probing on hardware killed both.

Probed live 2026-07-14 (dev box, cable out): keyword inert across 4s and 5s
in two runs; `dispatch forcerendererreload` inert too; only `hyprctl reload`
escapes — 99ms and 289ms. So: issue the keyword (enough whenever another
output is still enabled, e.g. the menu's Dock mode), and escalate to reload
only when `monitors` proves it inert. After a reload, re-assert the rule so a
config that parks the panel off cannot undo the undock, and restore per-device
keyboard layouts — a reload re-reads the config and drops the runtime
`device[<name>]:kb_layout` an external board depends on. The menu's `enable`
now proves itself against `monitors` too, instead of cheering for an exit code.

Verified V3 (partial): the fixed transition driven through a real unplug —
panel on, workspaces 1-3 home, 1.8s, `keyword=inert escalate=reload` ->
`enable=via-reload` -> `result=ok`. V2: nix flake check --no-build; docking-ux
+ dock-audio; monitor-fallback.nix; shellcheck clean on display-transition.

NOT proven, and queued as HARDWARE-QUEUE round 8: the watcher-driven path
(exec-once + baked store path = relogin required, the round-5 trap) and
repetition. The keyboard-restore path is untested — the dev box's keyboard
hangs off the dock's hub, so it leaves with the cable; round 8 adds a check
with a keyboard in the laptop. The VM harness still cannot reach any of this:
QEMU aborts Hyprland if the last active output is deleted while the DRM output
is disabled, which is the same zero-output degeneracy from the other side.

New BACKLOG #114 (PROPOSED): tuigreet ignores per-device keyboard layouts —
a VT has one keymap, so the greeter cannot honour `device[]:kb_layout`.
Bernardo hit it logging out while docked; not a regression, a design gap.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-07-14 12:28:06 +01:00
parent 28be6779a7
commit bec826baf0
5 changed files with 172 additions and 56 deletions

View File

@@ -132,11 +132,15 @@ pkgs.testers.runNixOSTest {
# behavior. Physical cable-yank timing remains the bounded V3 check.
#
# Undocking a quiescent output is therefore all this harness can assert
# and that gap is exactly what shipped a black panel in round 6: on real
# hardware the enable collides with the departing external's teardown and
# is silently dropped ~2 times in 3. The keyword re-issue in the
# transition and the tick-driven retry in the watcher are what cover it;
# neither is exercised below, so do not read a pass here as proof of them.
# and that gap is exactly what shipped a black panel in rounds 6 and 7.
# The real fault needs ZERO enabled outputs: with the panel disabled and
# the external gone, Hyprland 0.55.4 accepts `keyword monitor` and never
# flushes it, so the panel stays dark until some DRM event arrives (only
# `hyprctl reload` escapes it probed on hardware 2026-07-14). Note the
# QEMU abort above is that same degeneracy seen from the other side, so
# this harness cannot reach the state without dying in it: the undock here
# always runs while DP-1 is still enabled, i.e. the one case that never
# needed the fix. A pass below is NOT proof of the reload escalation.
user(f"{transition} undock Virtual-1")
machine.wait_until_succeeds(
hy + "-j monitors' | jq -e 'any(.[]; .name == \"Virtual-1\")'", timeout=20