jozamudi
0ceec0b4ab
recover-output-after-resume.sh existed to work around the old ThinkPad's /etc/modprobe.d/i915.conf, which forced PSR2 and the deepest display C-states; the flip pending across suspend never completed, so every later commit returned EBUSY and only a full modeset cleared it. That file is gone and this laptop's iGPU is driven by `xe` (Panther Lake has no i915 support at all), so the original cause cannot recur. The modeset is now conditional on the user journal actually reporting "Atomic commit failed"/"Page-flip failed" within the last 3 minutes. Unconditional disable/enable + `shikanectl reload` on every resume was itself a hazard: it is the exact sequence that re-triggers the shikane VariantInProgress deadlock the watchdog exists to recover from. hypridle.conf's comment no longer references the deleted i915.conf.
Josue's dotfiles
Uses GNU Stow to manage simlink. Place files as they where in $HOME
Usage
clone into $HOME
cd dotfiles
stow .
If stow is not installed use ./install.sh from .dotfiles repo
User services
shikane-watchdog
.config/systemd/user/shikane-watchdog.timer (every 2 min, user unit)
runs .config/sway/scripts/shikane-watchdog.sh, which restarts the
shikane user service if its state machine is stuck.
Why: shikane 1.1.1 deadlocks when a profile application is discarded
mid-way (e.g. by a failing DP atomic commit on the external display).
The daemon then keeps logging
[WARN shikane::variant] Received invalid input AtomicChangeDone at state Discarded
and shikanectl reload no longer recovers it. The watchdog detects
that signature in the journal and runs systemctl --user restart shikane
(re-applies the active profile in ~1s). It never restarts a healthy
or legitimately transitioning daemon.
systemctl --user status shikane-watchdog.timer # check it's active
systemctl --user disable --now shikane-watchdog.timer # disable