Bernardo Magri
ff5017ea5d
All checks were successful
Check / eval (push) Successful in 3m47s
Bernardo, live, right after #127 TEST A: undocked → the panel stayed dark; re-docked and undocked again → it came back. Re-docking is not what fixed it. OPENING THE LID was. awaiting_lid_open is set by every successful undock and cleared only when the external is gone AND the lid is open — so a clamshell undock latches it. Re-docking clears its sibling undock_pending ("a new external supersedes any undock still queued for an older departure") but not this one, and the clear cannot fire while an external is present. The next departure then hits the `[ -z "$awaiting_lid_open" ]` guard, queues nothing, and the panel never returns. His journal is unambiguous — the first undock logged NOTHING (no outputs-changed removed, no transition), then: 14:42:31 lid-inhibitor=released <- he opened the lid: latch cleared 14:42:40 outputs-changed added= DP-2 <- re-dock 14:42:47 outputs-changed removed= DP-2 transition=undock-queued 14:42:49 transition=undock result=ok Fix: clear the latch where undock_pending is already cleared — a new external ends the departure the latch describes. Replaying his sequence with the lid never opened: old = 1 of 3 undocks run, new = 3 of 3. This is very likely #127's SECOND symptom ("unplugging did not turn the laptop panel back on") and it has nothing to do with DPMS. Which raises the odds that the shipped mitigation is treating the wrong cause — TEST B now decides that, and with this fix an undock is a real escape hatch during it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>