caffeine.sh click was silently breaking idle lock. Two bugs that
compounded:
1. caffeine.sh inlined its own swayidle command (with swaylock -f -i
, not lock-fancy.sh), drifted out of sync with sway/config
which used lock-fancy.sh. Toggle off would restart swayidle with a
different lock command than the rest of the session.
2. WAYLAND_DISPLAY isn't set in waybar's on-click context. When
caffeine.sh called 'swaymsg output * power off' (part of the
restart command) and later called swaylock / grim (via lock-fancy),
those failed silently. swayidle itself can run without
WAYLAND_DISPLAY but it can't actually monitor input/output, so it
exits immediately. Result: user clicks caffeine off, flag clears,
icon goes back to 'inactive', but auto-lock is silently dead.
The user thinks they turned caffeine off. They didn't. They're
just unprotected.
Fix:
- new start-swayidle.sh holds the canonical swayidle command
- sway/config: exec $HOME/.config/sway/start-swayidle.sh
- caffeine.sh: killall swayidle; start-swayidle.sh &
- start-swayidle.sh probes /proc/*/environ for a Wayland client's
env (mako always has it) and exports WAYLAND_DISPLAY /
DBUS_SESSION_BUS_ADDRESS / XDG_RUNTIME_DIR / DISPLAY if missing
before exec'ing swayidle
Single source of truth + env restoration = click works on every box
that has the same Wayland-capable process tree (mako, swaybar, etc.),
no matter who/what is calling the script.
Verified on tadbit: pre-fix toggle off killed swayidle permanently.
Post-fix: toggle off restarts swayidle successfully, env inherited
from mako's /proc/PID/environ.
