hyprwm / hypridle

Hyprland's idle daemon
BSD 3-Clause "New" or "Revised" License
366 stars 21 forks source link

How to run multiple listener rules shortly after eachother #86

Closed BBaoVanC closed 2 weeks ago

BBaoVanC commented 4 weeks ago

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:

listener {
    timeout = 300
    on-timeout = loginctl lock-session
}

listener {
    timeout = 330
    on-timeout = hyprctl dispatch dpms off
    on-resume = hyprctl dispatch dpms on
}

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?

vaxerski commented 4 weeks ago

what's the lock-session command? sounds like it somehow trips hyprland to think that you're back

BBaoVanC commented 4 weeks ago

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 ```conf general { grace = 5 no_fade_out = true } background { monitor = color = rgba(150, 150, 150, 1.0) # fallback if bg doesn't work #path = ~/wallpaper path = ~/wallpapers/nord_wp1.png blur_passes = 3 } label { monitor = text = cmd[update:1000] echo "$(date '+%A, %b %d%n%I:%M:%S %p')" text_align = center font_size = 20 font_family = JetBrains Mono halign = center valign = top position = 0, -25 } label { monitor = text = $USER text_align = center font_size = 12 font_family = JetBrains Mono halign = center valign = bottom position = 0, 25 } # https://wiki.hyprland.org/Hypr-Ecosystem/hyprlock/#input-field input-field { monitor = size = 600, 50 outline_thickness = 3 dots_size = 0.33 # Scale of input-field height, 0.2 - 0.8 dots_spacing = 0.15 # Scale of dots' absolute size, 0.0 - 1.0 dots_center = false dots_rounding = -1 # -1 default circle, -2 follow input-field rounding outer_color = rgb(151515) inner_color = rgb(200, 200, 200) font_color = rgb(10, 10, 10) fade_on_empty = true fade_timeout = 1000 # Milliseconds before fade_on_empty is triggered. placeholder_text = Input Password... # Text rendered in the input box when it's empty. hide_input = false rounding = -1 # -1 means complete rounding (circle/oval) check_color = rgb(204, 136, 34) fail_color = rgb(204, 34, 34) # if authentication failed, changes outer_color and fail message color fail_text = $FAIL ($ATTEMPTS) # can be set to empty fail_timeout = 2000 # milliseconds before fail_text and fail_color disappears fail_transition = 300 # transition time in ms between normal outer_color and fail_color capslock_color = -1 numlock_color = -1 bothlock_color = -1 # when both locks are active. -1 means don't change outer color (same for above) invert_numlock = false # change color if numlock is off swap_font_color = false # see below position = 0, -20 halign = center valign = center } ```
vaxerski commented 3 weeks ago

can you try to set an explicit command for on-lock in hypridle? that's what should be run on loginctl lock-sesison

BBaoVanC commented 3 weeks ago

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.

vaxerski commented 3 weeks ago

hm, odd. I think this is a hyprland issue.

eeelbrens commented 3 weeks ago

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?

vaxerski commented 3 weeks ago

order of listeners is irrelevant, all run at the same time

eeelbrens commented 3 weeks ago

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

BBaoVanC commented 3 weeks ago

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

eeelbrens commented 3 weeks ago

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?

vaxerski commented 3 weeks ago

no, should be reported in hyprland prolly

BBaoVanC commented 3 weeks ago

Alright, I guess I'll make an issue report over there

izmyname commented 2 weeks ago

https://github.com/hyprwm/hypridle/issues/80 prolly related, judging from the description.

eeelbrens commented 2 weeks ago

it is indeed the same

vaxerski commented 2 weeks ago

closing as dupe then