-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
Description
After upgrading to Hyprland 0.54.0, when hypridle timeout calls loginctl lock-session, Hyprland's internal session lock is triggered instead of the configured lock_cmd in hypridle.conf.
Environment
- Hyprland: 0.54.0
- hypridle: latest
- swaylock: 1.7.0.0
- OS: Arch Linux
Configuration
hypridle.conf:
general {
lock_cmd = ~/.config/hypr/scripts/lock.sh
before_sleep_cmd = loginctl lock-session
after_sleep_cmd = hyprctl dispatch dpms on
}
listener {
timeout = 300
on-timeout = loginctl lock-session
}
listener {
timeout = 380
on-timeout = hyprctl dispatch dpms off
on-resume = hyprctl dispatch dpms on
}lock.sh:
#!/usr/bin/env bash
swaylock --clock \
--indicator \
--indicator-radius 100 \
--indicator-thickness 7 \
...Behavior
-
Manual lock (Win+L →
loginctl lock-session): Works correctly, swaylock is triggered via hypridle'slock_cmd. -
Idle timeout (hypridle →
loginctl lock-session): Hyprland's internal session lock is triggered instead. The screen shows a basic lock that only allows exiting the session, not the configured swaylock.
Workaround
Bypass dbus by calling the lock script directly in the listener:
listener {
timeout = 300
on-timeout = ~/.config/hypr/scripts/lock.sh
}Analysis
From hypridle verbose log, I can see that Hyprland 0.54.0 now has ext_session_lock_manager_v1 protocol support. It seems that when hypridle's timeout triggers loginctl lock-session, Hyprland's internal session lock handler intercepts the signal before hypridle's lock_cmd can execute.
This appears to be a race condition or priority issue between Hyprland's internal session lock and hypridle's dbus lock event handling.
Expected Behavior
When hypridle timeout triggers loginctl lock-session, it should execute the configured lock_cmd (swaylock in this case), just like when manually calling loginctl lock-session.
Related
- lock-session doesn't trigger hyprlock hypridle#115 - Similar issue reported