Closed nexussapphire closed 5 months ago
what does that have to do with hypridle?
For some reason running this app stops the system from properly suspending through the command. It works every time when the daemon isn't running.
I just tested swayidle and it works too. I'd really like this application to work because the documentation is poor for swayidle. Every time I forget how the config file for it works it's like beating your head against a wall.
...huh.
I don't know why, I see it receive something or do something just before the screen goes black. I tried to pipe the output into a file but I'm not good at pipes yet or it just doesn't work that way. I scowered the arch forums and found little on getting detailed information about what's holding up sleep.
I'd like to trigger the lock screen before it goes to sleep but I removed the before-sleep variable in case it was some sort of race condition but it still hangs. It's not important for it to work right now but it would be nice to ad a sleep button to the system tray later and I assumed you'd want to know.
If you need any help at all let me know, I like what you guys are doing.
If it helps I have:
system 76 pangolin 13 - Ryzen 7 5700U
latest linux-zen.
Hyperland.
The AMD video drivers that come with the kernel.
...huh.
I tested swayidle and all forms of suspend work just like if nothing is running. I was trying to isolate the issue and it's hypridle or something I'm missing something.
...huh.
I tested swayidle and all forms of suspend work just like if nothing is running. I was trying to isolate the issue and it's hypridle or something I'm missing something.
For me its working perfectly, share your hypridle
config. This is mine ->
general {
lock_cmd = pgrep hyprlock || hyprlock # dbus/sysd lock command (loginctl lock-session)
before_sleep_cmd = playerctl pause ; hyprlock # command ran before sleep
#after_sleep_cmd = # command ran before sleep
ignore_dbus_inhibit = false # whether to ignore dbus-sent idle-inhibit requests (used by e.g. firefox or steam)
}
listener {
timeout = 300 # in seconds
on-timeout = loginctl lock-session # command to run when timeout has passed
#on-resume = # command to run when activity is detected after timeout has fired.
}
Here's the hypridle config file I'm using. Ive tried a config that only turns the screen off at a certain time and a version that doesn't have before_sleep_cmd
. I've also jumped from stable to git version to see if the problem goes away.
In all cases it fales to go to sleep when the systemctl suspend
command is run and sometimes when I close the lid.
I have all the system76 software relevant to my pangolin 13 installed and enabled.
before_sleep_cmd = swaylock -f
}
listener {
timeout = 300
on-timeout = hyprctl dispatch dpms off & swaylock -f
on-resume = hyprctl dispatch dpms on
}
listener {
timeout = 600
on-timeout = systemctl suspend
}
Sorry it took so long to get back, nine hour days at the plant nursery and it's been kicking my but.
I have it on my desktop as well and can confirm it works as intended on my desktop.
@nexussapphire do these things for debugging ->
killall hypridle
hypridle
sysemtctl suspend
These are my output and config. Try to match and debug ->
hypridle log, i have removed starting log as they are redundant ->
[LOG] found 3 rules
[LOG] wayland done, registering dbus
[LOG] Using dbus path /org/freedesktop/login1/session/_31
[LOG] Got PrepareForSleep from dbus with sleep true
[LOG] Running: loginctl lock-session & playerctl pause
[LOG] Executing loginctl lock-session & playerctl pause
[LOG] Process Created with pid 5806
[LOG] Got dbus .Session
[LOG] Got Lock from dbus
[LOG] Locking with pidof hyprlock || hyprlock -q
[LOG] Executing pidof hyprlock || hyprlock -q
[LOG] Process Created with pid 5822
[LOG] Got PrepareForSleep from dbus with sleep false
[LOG] Running: hyprctl dispatch dpms on
[LOG] Executing hyprctl dispatch dpms on
[LOG] Process Created with pid 6126
ok
hypridle config ->
# Documentation: https://wiki.hyprland.org/Hypr-Ecosystem/hypridle
general {
lock_cmd = pidof hyprlock || hyprlock -q
unlock_cmd = killall -q -s SIGUSR1 hyprlock
before_sleep_cmd = loginctl lock-session & playerctl pause
after_sleep_cmd = hyprctl dispatch dpms on
ignore_dbus_inhibit = false
}
listener {
timeout = 300
on-timeout = loginctl lock-session
}
listener {
timeout = 600
on-timeout = hyprctl dispatch dpms off
}
listener {
timeout = 1800
on-timeout = systemctl suspend-then-hibernate
}
when systemctl suspend is entered into the terminal it doesn't successfully suspend. It does suspend properly when the laptop lid is closed. I think it suspends when triggered by a timer also.
do you mean that it dosen't suspend instantly? Because i was also having this issue, you just have to wait 10 seconds or something, as this is the case for me. But this dosen't happen when i do systemctl suspend
in KDE. Try waiting for about 30seconds and if this is the case then another issue needs to be open.
Edit - Ok forgot about the above which is just strikedthrough. For me, i am have enabled suspend-then-hibernate
for lid-close event and i misunderstood your issue and related it to mine ( which also might not be actual issue, as it may be just how suspend-then-hibernate
behaves).
Is there any way to log to a file because it doesn't respond to anything but holding the power button down and the screen turns off instantly.
Is there any way to log to a file because it doesn't respond to anything but holding the power button down and the screen turns off instantly.
hypridle -v &> hypridle_output.log
then open the file ~/hypridle_output.log
also check dpms section of hyprland_wiki for black_screen. maybe you are turning on dpms but you have not enabled on how to turn it off.
I have the exact same config on my desktop, the dpms works. I'll log it when I get a chance.
Setting it up with the help of the new wiki and maybe some updates you guys did helps. I notice some weird behavior still like my laptop not going to sleep every time the lid is closed. Usually when I open it then close it right away. here's the log with me suspending it two times. Sometimes it happens the first time after a fresh boot and sometimes it happens after I've had my laptop on for a while and then put it to sleep.
I'm not sure how much help I'll be the next three days because after a long day at work I wont feel like studying hunched over a laptop.
[LOG] wayland done, registering dbus
[LOG] Using dbus path /org/freedesktop/login1/session/_32
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[[TRACETRACE] ] got dbus event[core] got poll event
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got PrepareForSleep from dbus with sleep true
[LOG] Running: loginctl lock-session
[LOG] Executing loginctl lock-session
[LOG] Process Created with pid 3588
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE]ok
3689 3685
ok
[core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got dbus .Session
[LOG] Got Lock from dbus
[LOG] Locking with pidof swaylock || swaylock
[LOG] Executing pidof swaylock || swaylock
[LOG] Process Created with pid 3597
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got PrepareForSleep from dbus with sleep false
[LOG] Running: hyprctl dispatch dpms on
[LOG] Executing hyprctl dispatch dpms on
[LOG] Process Created with pid 3688
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got PrepareForSleep from dbus with sleep true
[LOG] Running: loginctl lock-session
[LOG] Executing loginctl lock-session
[LOG] Process Created with pid 3726
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got dbus .Session
[LOG] Got Lock from dbus
[LOG] Locking with pidof swaylock || swaylock
[LOG] Executing pidof swaylock || swaylock
[LOG] Process Created with pid 3734
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] got dbus event
[LOG] Got PrepareForSleep from dbus with sleep false
[LOG] Running: hyprctl dispatch dpms on
[LOG] Executing hyprctl dispatch dpms on
[LOG] Process Created with pid 3771
[TRACE] got dbus event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got poll event
[TRACE] [core] got pol
I'll try it as is, I might be fighting against my laptops firmware or something without noticing while I'm testing this. It might be best to live with it now there isn't a chance of multiple instances of sway lock enabling. I don't know if the sleep timers keep going after suspend tbh.
I think I figured it out. On my desktop it seems to launch swaylock three times. It sometimes seems to hang during suspend or fail to successfully activate the lock screen until I killall swaylock
. I had the pidof swaylock || swaylock
.
If I suspend then resume on my desktop then run pidof swaylock
I get three numbers kind of like 1256 1258 1231
.
I'd need to test it on my laptop, it may have to do with Nvidia graphics on my desktop and have nothing to do with my laptop.
I may have a similar issue.
Here is my config in nix:
settings = {
general = {
after_sleep_cmd = "${hyprctl} dispatch dpms on"; # turn on display after resume.
before_sleep_cmd = "${loginctl} lock-session"; # lock before suspend.
lock_cmd = "pidof hyprlock || ${hyprlock}"; # lock screen.
};
listener = [
{
timeout = 300;
on-timeout = "${loginctl} lock-session"; # lock screen.
}
{
timeout = 330;
on-timeout = "${hyprctl} dispatch dpms off"; # turn off display.
on-resume = "${hyprctl} dispatch dpms on"; # turn on display.
}
{
timeout = 600;
on-timeout = "${systemctl} suspend"; # suspend.
}
];
};
I believe that since we lock the session before we suspend, hypridle does not have the correct userland permissions to suspend.
This is the output i get from hypridle.service
, which I believe corroborates with my explanation.
Jun 15 13:28:06 slaptop systemctl[137717]: Call to Suspend failed: Connection timed out
Jun 15 13:28:10 slaptop systemctl[137717]: Failed to start suspend.target: Access denied
Jun 15 13:28:10 slaptop systemctl[137717]: See system logs and 'systemctl status suspend.target' for details.
It may be because hypridle is run as a user space service? However I also have a swayidle config (swayidle also runs in user space) and that works fine.
@nexussapphire
I notice some weird behavior still like my laptop not going to sleep every time the lid is closed. Usually when I open it then close it right away.
This is the default behaviour of systemd-logind, when you suspend - then open the lid - then close the lid, there is 90 sec cooldown timer which won't let the system suspend. I read it somewhere on man page but now i can't find it now.
You are confusing what hypridle does. Hypridle job is to
The output you showed show that your systemctl
command is failing and not hypridle. Try this in terminal - systemctl suspend
does it work? If not try fixing that.
Also it said in the output Jun 15 13:28:10 slaptop systemctl[137717]: See system logs and 'systemctl status suspend.target' for details.
please try that to dignose your issue.
@KAGEYAM4 Yes I am aware.
I was just wondering whether it was the same (non-hypridle related) issue that nexussapphire had.
If that is the case, then it is an issue with the order of operations with hypridle.
nexussapphire issue got solved , but i am still not sure what the exact issue was LOL, @nexussapphire please close this issue, if it's been solved.
@sjcobb2022 i understand, but in your case you don't have to wonder. Did you try the two commands above to obtain some logs? Because at this point we are just guessing. Please run those two to troubleshoot unless nix operates totally different way. I only have expieriece with mutable distro.
I don't know, it never got solved. I'll close the issue anyways because I switched to KDE and can't really help anymore. The keyboard being stuck on one window when focus changes over to another window just got to me after issues with other little stuff like waybar failing to launch on my laptop on initial login.
when systemctl suspend is entered into the terminal it doesn't successfully suspend. It does suspend properly when the laptop lid is closed. I think it suspends when triggered by a timer also.