Closed BBaoVanC closed 2 months ago
what's the lock-session command? sounds like it somehow trips hyprland to think that you're back
I am not really sure how lock-session works to be honest; I just set what I have above in hypridle.conf and my hyprlock.conf is just widget customization. Is there something else I was supposed to set?
hyprlock.conf
can you try to set an explicit command for on-lock
in hypridle? that's what should be run on loginctl lock-sesison
After changing general:lock_cmd
to notify-send hyprlock
, it works as expected and the monitors turn off 3 seconds after I get the test notification. So I guess something is wrong with hyprlock causing it to wake up somehow.
If it's relevant (forgot to mention this in the main post), I'm running on
Using proprietary NVidia driver 555.58.02-1, although I wouldn't think this would impact locking? Tomorrow I should be able to test this on my AMD computer to see if it does.
Edit: Same issue on my AMD machine. Also, if I change the 300 second listener to call hyprlock
directly instead of loginctl lock-session
, I still have the same issue.
hm, odd. I think this is a hyprland issue.
However, the above config locks the screen after 5 minutes, and then turns the screen off 5m 30s after that (a total of 10m 30s). Is this intended behavior? It closely mirrors the example in the docs.
If intended, what can I change to make it turn the screen off only 30 seconds later after locking?
Yeah I've had this issue too. After some troubleshooting && timekeeping I detected some spooky behavior. For example in this hypridle.conf
:
general {
lock_cmd = pidof hyprlock || hyprlock
before_sleep_cmd = hyprlock
}
listener {
timeout = 450
on-timeout = hyprlock
on-resume = notify-send "Welcome back!"
}
listener {
timeout = 90
on-timeout = systemctl suspend
}
It seems to ignore the order of which listeners are written and it only picked the listeners with least timeout (descending order) and not running listeners simultaneously or even strictly in order. Also general:lock_cmd = notify-send hyprlock
didn't fix the issue for me.
For good measure, I installed the latest hyprland tagged version with all its utils recently:
hyprland v0.42.0-1
hypridle v0.1.2-1
@BBaoVanC @vaxerski does this ring any bells to you?
order of listeners is irrelevant, all run at the same time
order of listeners is irrelevant, all run at the same time
well they don't for me. maybe the listeners "reset" themselves or smth but for real I don't know why every listener in config must take its timeout time, hence the issue
order of listeners is irrelevant, all run at the same time
well they don't for me. maybe the listeners "reset" themselves or smth but for real I don't know why every listener in config must take its timeout time, hence the issue
At least based on the behavior for me, somehow hyprlock is causing it to think it was woken up and not idle anymore
order of listeners is irrelevant, all run at the same time
well they don't for me. maybe the listeners "reset" themselves or smth but for real I don't know why every listener in config must take its timeout time, hence the issue
At least based on the behavior for me, somehow hyprlock is causing it to think it was woken up and not idle anymore
then any possible solution on our end?
no, should be reported in hyprland prolly
Alright, I guess I'll make an issue report over there
it is indeed the same
closing as dupe then
I am trying to get hypridle to lock the screen after 5 minutes, and then turn the screen off 30 seconds after that (so 5m 30s in total). I expected that this would do that:
However, the above config locks the screen after 5 minutes, and then turns the screen off 5m 30s after that (a total of 10m 30s). Is this intended behavior? It closely mirrors the example in the docs.
If intended, what can I change to make it turn the screen off only 30 seconds later after locking?