lock-session doesn't trigger hyprlock

[Joao-Queiroga]

When the listener does the lock-session command, or when its done manually, it doesn't trigger hyprlock.
Here is my config:

general {
  lock_cmd = pidof hyprlock || hyprlock       # avoid starting multiple hyprlock instances.
  before_sleep_cmd = loginctl lock-session    # lock before suspend.
  after_sleep_cmd = hyprctl dispatch dpms on  # to avoid having to press a key twice to turn on the display.
  ignore_dbus_inhibit = false             # whether to ignore dbus-sent idle-inhibit requests (used by e.g. firefox or steam)
  ignore_systemd_inhibit = false          # whether to ignore systemd-inhibit --what=idle inhibitors
}

listener {
    timeout = 150                                # 2.5min.
    on-timeout = brightnessctl -s set 10         # set monitor backlight to minimum, avoid 0 on OLED monitor.
    on-resume = brightnessctl -r                 # monitor backlight restore.
}

listener {
    timeout = 300                                 # 5min
    on-timeout = loginctl lock-session            # lock screen when timeout has passed
}

listener {
    timeout = 330                                 # 5.5min
    on-timeout = hyprctl dispatch dpms off        # screen off when timeout has passed
    on-resume = hyprctl dispatch dpms on          # screen on when activity is detected after timeout has fired.
}

I am using hypridle 0.1.5 and Hyprland 0.45.2 on gentoo using openrc

[vaxerski]

is hypridle spawned from hyprland or a service? If a service, it doesn't share the same environment as hyprland, so hyprlock cannot start because it doesn't know where to start

[Joao-Queiroga]

its started from hyprland its not systemd.

[Joao-Queiroga]

I switched to systemd on gentoo to test it and it works. I think its a problem when comunicating to logind or dbus.

[vaxerski]

your env is somehow not propagating correctly.

[Quasar-0330]

Does not work in Arch either.

[Quasar-0330]

Looks like it's already been fixed.
It works in my environment

[vaxerski]

@Joao-Queiroga ?

[jetm]

I am using Arch Linux too, and maybe a specific case. I had the same problem. It started working for me after starting using uwsm and enabling hypridle.service; I had my own systemd service.

For the case of Arch Linux, make sure hyrplock is not crashing because of the wrong hyprutils library.

[Joao-Queiroga]

I actualy went back to arch and it stopped. I think it has something to do with elogind.

[LelouBil]

is hypridle spawned from hyprland or a service? If a service, it doesn't share the same environment as hyprland, so hyprlock cannot start because it doesn't know where to start

So, if using uwsm to start hyprland, I should not be using hypridle.service ?

I should still have exec-once=hypridle ?

I am having the same issue, I just migrated to uwsm, things like hyprpolkitagent work fine when started by systemd, hypridle starts without error and receives lock events, but does not trigger hyprlock.

when doing loginctl lock-session I get

[LOG] Got dbus .Session
[LOG] Got Lock from dbus

in the hypridle logs but no locking happening

Whoops, config issue on my end, I thought hypridle supported the "source" config, but it didn't, and the error did not stop it from starting. But my previous question still stands because I didn't understand your comment.

[viv223345]

hypridle now has config source support . this issue still occurs, however.

there is a workaround: source everything, but keep general:lock_cmd in the main config file. my config:

# Source Files Directory
$source = src/idle

# General
source = $source/general

# Listeners
source = $source/brightness.conf 	        # Lower brightness
source = $source/lock.conf			# Lock
source = $source/suspend.conf		        # Suspend

general {
    lock_cmd = pidof hyprlock || hyprlock
}