Hyprland locking, idle policy and companion services

On this page

Locking, turning displays off and suspending the system are different actions. A black screen does not prove that authentication protects the session.

Give policy one owner

ActionEffectDoes not imply
LockRestricts interaction through authenticationDisplay power is off
DPMS offDisables display outputSession is locked or processes stopped
SuspendEnters system low-power stateLocking completed beforehand

The current example uses Caelestia for idle and locking. An earlier setup used hypridle/hyprlock. Running both policies can cause duplicate locks, repeated DPMS changes and conflicting timers.

Current idle configuration

This fragment belongs at general.idle in Caelestia v2.4.0's complete shell.json:

{
  "lockBeforeSleep": true,
  "inhibitWhenAudio": true,
  "inhibitWhenCharging": false,
  "timeouts": [
    {
      "timeout": 3600,
      "idleAction": "lock",
      "respectInhibitors": true
    },
    {
      "timeout": 3900,
      "idleAction": "dpms off",
      "returnAction": "dpms on",
      "respectInhibitors": false
    }
  ]
}

Locking respects inhibitors while the later display-off action does not; input return restores output. These are separate idle decisions, not necessarily “300 seconds after locking finishes”. If locking is inhibited but display power is not, the display can turn off while the session remains unlocked.

Decide whether that state is acceptable. A requirement to lock before display-off needs an explicitly tested sequence, not only two timeout values. Caelestia configuration

Understand inhibitor scope

Applications can request that playback prevent idle behaviour through Wayland, D-Bus or logind mechanisms. These are not one universal list.

systemd-inhibit --list

This lists logind inhibitors. An empty result does not rule out Wayland inhibition. Combine shell logs, playback state and protocol-specific evidence rather than blaming a particular D-Bus lock merely because a browser is open.

Test locking and display recovery

Save work and retain a recovery route, then:

  1. Lock manually and verify authentication is required.
  2. Unlock and check keyboard layout, input method and every output.
  3. Test idle timeouts without playback or inhibitors.
  4. Compare audio and video playback.
  5. Test DPMS off and input return, including the intended lock state.
  6. Finally test suspend/resume and whether locking completes before sleep.

Temporarily shortened timers should be restored afterwards. Record event times; darkness alone is not an authentication or recovery test.

The hypridle/hyprlock alternative

Without shell-owned idle management, hypridle can trigger hyprlock. Define lock commands, pre-suspend actions, display restoration and inhibitor policy using the installed version's documentation.

The historical two-instance solution separated lock and display-power inhibition. Do not copy it into the current Caelestia setup; per-listener or shell policy may already express the requirement. Verify process count and ownership after choosing an arrangement.

loginctl lock-session requests locking and needs a session component to respond. Verify actual authentication UI and logs, not only command exit status.

Other desktop functions

FunctionIndependent examplesIntegration check
Launching/selectionFuzzel, WalkerExisting shell launcher and executable paths
Clipboard historycliphist, wl-clipboardRunning watcher and text/image behaviour
Input methodsFcitx5GTK, Qt, Wayland and XWayland cases
Wallpaperhyprpaper or shell backgroundOnly one owner per output
Power menuwlogout or shell menuActual action behind each button

See Matugen for colours, Neovim input for mode switching and session diagnosis for startup issues.