Hypridle reporting that Niri does not implement hyprland-lock-notify-v1

[alisonjenkins]

hypridle is logging:

[WARN] Compositor is missing hyprland-lock-notify-v1!

This seems to prevent hypridle from knowing when the lock command has been executed and as a result when suspending the machine it doesn't get to lock the screen before suspending.

This then means that when the machine is awoke it is briefly not locked and any sensitive information on the screen is visible for a short time period before the lock screen starts.

The documentation on this protocol can be found here

System Information

• niri version: niri unstable 2025-10-02 (commit ba6e5e082a79901dc89b0d49c5da1b769d652aec)

• Distro: NixOS

• GPU: AMD Radeon 6900XT

• CPU: AMD Ryzen 9 7950X

[HigherOrderLogic]

This seems to prevent hypridle from knowing when the lock command has been executed and as a result when suspending the machine it doesn't get to lock the screen before suspending.

I used Hypridle before switching to Swayidle and this didnt happen to me.

Also looking at the source code, it seems that this protocol is not related to your issue. Feel free to correct me.

https://github.com/hyprwm/hypridle/blob/f158b2fe9293f9b25f681b8e46d84674e7bc7f01/src/core/Hypridle.cpp#L104-L105

[alisonjenkins]

This seems to prevent hypridle from knowing when the lock command has been executed and as a result when suspending the machine it doesn't get to lock the screen before suspending.

I used Hypridle before switching to Swayidle and this didnt happen to me.

Also looking at the source code, it seems that this protocol is not related to your issue. Feel free to correct me.

https://github.com/hyprwm/hypridle/blob/f158b2fe9293f9b25f681b8e46d84674e7bc7f01/src/core/Hypridle.cpp#L104-L105

So from my understanding of the hypridle code these lines are stating that the following settings at least will not work:

general:inhibit_sleep=3, general:on_lock_cmd and general:on_unlock_cmd

The one in particular that leads me to believe this is the reason that suspend happens before the locking has been completed is that the documentation around general:inhibit_sleep=3 states here:

The general:inhibit_sleep option is used to make sure hypridle can do certain tasks before the system goes to sleep.

Options:

    3 makes your system wait until the session gets locked by a lock screen app. This works with all wayland session-lock apps.
    2 (auto) selects either 3 or 1 depending on whether hypridle detects if you want to launch hyprlock before sleep.
    1 makes the system wait until hypridle launched general:before_sleep_cmd.
    0 disables sleep inhibition.

So it clearly states in the code that inhibit_sleep 3 will not work and the docs also state that this means that the lock app isn't guaranteed to have completed before the system goes to sleep and this is the behavior that lead me to go looking into this.

[alisonjenkins]

This seems to prevent hypridle from knowing when the lock command has been executed and as a result when suspending the machine it doesn't get to lock the screen before suspending.

I used Hypridle before switching to Swayidle and this didnt happen to me.

Also looking at the source code, it seems that this protocol is not related to your issue. Feel free to correct me.

https://github.com/hyprwm/hypridle/blob/f158b2fe9293f9b25f681b8e46d84674e7bc7f01/src/core/Hypridle.cpp#L104-L105

So for now I have swapped from hyperidle to swayidle as I was able to get that to actually lock and run scripts prior to suspend via it's -w option. However swayidle doesn't have all the functionality that hyperidle has so I would still rather use hyperidle but afaict there is no configuration of hyperidle that functions properly without this protocol on Niri.

[BBaoVanC]

For people who haven't seen the linked PR, YaLTeR mentioned that niri already notifies the locked hint over dbus -- perhaps this means instead, an issue should be raised with hypridle to just support reading the LockedHint from logind dbus instead of needing to implement the hyprland protocol in every compositor.

[brianmercer]

I'm using hypridle and hyprlock on niri and ran into this issue of desktop flash when resuming.

For me it's not a problem with idle time action in hypridle, I can set hypridle to lock after 5 minutes and then suspend after 15 minutes. The problem is hypridle failing to run before suspend when pressing the power button. When systemd controls the power button, it suspends before hypridle has time to draw. Probably not a niri issue.

I worked around it by disabling power button handling in systemd-logind, and using a script from niri.

# /etc/systemd/logind.conf.d/login.conf

[Login]
HandlePowerKey=ignore

# /home/anonymous/.config/niri/config.kdl
...
binds {
...
    XF86PowerOff { spawn-sh "/home/anonymous/.local/bin/lock-and-suspend.sh | systemd-cat -t LockAndSuspend"; }
}

#!/bin/bash
# /home/anonymous/.local/bin/lock-and-suspend.sh

echo "Running lock-and-suspend.sh"

if ! pidof hyprlock > /dev/null; then
    echo "hyprlock is not running, so run it"
    hyprlock --no-fade-in --immediate-render &
fi

sleep 1.0

echo "Now suspend"
systemctl suspend

# /home/anonymous/.config/hypr/hypridle.conf

general {
    lock_cmd = pidof hyprlock || hyprlock
    ignore_dbus_inhibit = false
    ignore_systemd_inhibit = false
}

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

listener {
    timeout = 900
    on-timeout = systemctl suspend
}

# journalctl -f
Mar 15 18:47:31 talc systemd-logind[726]: Power key pressed short.
Mar 15 18:47:31 talc LockAndSuspend[116936]: Running lock-and-suspend.sh
Mar 15 18:47:31 talc systemd[20451]: Started app-niri-sh-116934.scope.
Mar 15 18:47:31 talc LockAndSuspend[116936]: hyprlock is not running, so run it
Mar 15 18:47:31 talc uwsm_niri.desktop[20542]: 2026-03-15T22:47:31.668670Z  INFO niri::niri: locking session
Mar 15 18:47:31 talc systemd[1]: Starting Fingerprint Authentication Daemon...
Mar 15 18:47:31 talc kernel: usb 1-5: reset full-speed USB device number 3 using xhci_hcd
Mar 15 18:47:32 talc systemd[1]: Started Fingerprint Authentication Daemon.

Broadcast message from anonymous@talc (Sun 2026-03-15 18:47:32 EDT):

The system will suspend now!

Mar 15 18:47:32 talc LockAndSuspend[116936]: Now suspend
Mar 15 18:47:32 talc systemd-logind[726]: The system will suspend now!
Mar 15 18:47:32 talc rtkit-daemon[725]: Demoting known real-time threads.
Mar 15 18:47:32 talc hypridle[103087]: [LOG] Got PrepareForSleep from dbus with sleep true
Mar 15 18:47:32 talc hypridle[103087]: [LOG] Releasing the sleep inhibitor!

That's using uwsm, but it should do the same without. Niri locks properly when hyprlock runs.