Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timer keeps running while sleeping #73

Open
ehula opened this issue Jun 24, 2024 · 12 comments
Open

timer keeps running while sleeping #73

ehula opened this issue Jun 24, 2024 · 12 comments

Comments

@ehula
Copy link

ehula commented Jun 24, 2024

I have one of my listeners set to suspend. However, if I manually suspend (like close the lid), it seems that hypridle's timer keeps running. If I don't resume my laptop until after the suspend timeout period has lapsed, as soon as my laptop finishes resuming, hypridle immediately suspends it again.

Can you either pause the timer while sleeping, or reset the timer or restart hypridle on resume?

This was not a problem with swayidle.

@saharshbhansali
Copy link

Yup, I am facing the same issue.

I tried to inhibit the suspension by using a "lock" file:

on-timeout = cat /tmp/hypridle-lock || touch /tmp/hypridle-lock && systemctl suspend

and

on-resume = rm /tmp/hypridle-lock

And also doing the same when I encounter a lid close event and lid open event.

But it seems like that workaround fails.

@muni-corn
Copy link

can confirm i'm facing the same issue. this happens on both my desktop and my laptop. suspending and then immediately waking is fine, but waking after a long time of sleep (my sleep timeout is set to 30 minutes) causes the system to immediately suspend again.

@saharshbhansali
Copy link

saharshbhansali commented Jul 5, 2024

And also doing the same when I encounter a lid close event and lid open event.

But it seems like that workaround fails.

I've also tried another workaround, which is to kill hypridle using bindl = , switch:on:Lid Switch, ..., and then run the same commands used in the on-resume section of each listener along with restarting hypridle with switch:off:Lid Switch.

Killing hypridle works, and the timer stops (cause duh), but hypridle doesn't restart, nor do the on-resume section commands seem to run properly.

So, in the end, this workaround appears to fail as well.

@HarshNarayanJha
Copy link

The exact same behavior is occurring to me also. Laptop immediately suspends when I open the lid.

@mike-lloyd03
Copy link

I've noticed that if I suspend the laptop manually (by running systemctl suspend) and wake the machine after the timer expires with a key press, it does not immediately suspend again. But if I suspend it by closing the lid, it will suspend again after opening the lid.

My theory is that hypridle does not recognize the lid switch event as activity and does not reset the idle timer when waking the machine by opening the lid.

@VinzNL
Copy link

VinzNL commented Jul 13, 2024

Same here. It doesn't always happen, but when it happens it's usually after I've closed the lid and let it go to suspend-then-hibernate and let it go to hibernate 4 hours later. When I resume the laptop from hibernation it immediately goes back to suspend.

@HarshNarayanJha
Copy link

What about using hypridle as a systemd-service, and stopping it before suspend and starting it after suspend?

@gwstorm
Copy link

gwstorm commented Jul 14, 2024

I've found an actual workaround for the moment. I'd much rather have it all handled solely through hypridle, but this works for now. If you remove the suspend block from hypridle and use /etc/systemd/logind.conf to control your suspending, then the system actually realizes that it was put to sleep and the timer won't trigger again on wake.

In my case, I created /etc/systemd/logind.conf.d/logind.conf to make sure it survives updates and just put in the following -

[Login]
SleepOperation=suspend
IdleAction=suspend
IdleActionSec=20min

And a standard hypridle config -

general {
    lock_cmd = hyprlock
    before_sleep_cmd = loginctl lock-session
    after_sleep_cmd = hyprctl dispatch dpms on
}

# Screenlock
listener {
    timeout = 600
    on-timeout = loginctl lock-session
}

# Turn off screen
 listener {
     timeout = 630
     on-timeout = hyprctl dispatch dpms off
     on-resume = hyprctl dispatch dpms on
 }

@fjueic
Copy link

fjueic commented Jul 15, 2024

came here from a reddit post

im using this restarting hypridle on wake

    general={
        "lock_cmd": ["pidof hyprlock ||  hyprlock"],
        "unlock_cmd": ["pkill -USR1 hyprlock"],
        "before_sleep_cmd": ["loginctl lock-session"],
        "after_sleep_cmd": [
            "(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)"
        ],
        "ignore_dbus_inhibit": [False],
    },
    listener=[
        # Screenlock
        {
            "timeout": [300],
            "on-timeout": ["loginctl lock-session"],
        },
        # Suspend
        {
            "timeout": [600],
            "on-timeout": ["systemctl suspend"],
        },
    ],

@gwstorm
Copy link

gwstorm commented Jul 16, 2024

@fjueic , it looks like the python got cut from the beginning of your code block because it wasn't on the next line after the ```, so if dropped in as is, it will error out with no rules configured. However, taking those components and dropping them into standard hypridle syntax works perfectly and is a much better solution than mine at the moment. Thanks for sharing this.

@fjueic
Copy link

fjueic commented Jul 16, 2024

it looks like the python got cut

yes i didn't copy entire file, just wanted to give to an idea

it will error out with no rules configured

i don't use hyprlang to configure hyprwm programs like hyprpaper, hypridle, and hyprland itself. I have a custom library(just one big file) written in python.

So, i just wanted to give a reference as there was no point in sharing the irrelevant python code

@C-798
Copy link

C-798 commented Aug 20, 2024

came here from a reddit post

im using this restarting hypridle on wake

    general={
        "lock_cmd": ["pidof hyprlock ||  hyprlock"],
        "unlock_cmd": ["pkill -USR1 hyprlock"],
        "before_sleep_cmd": ["loginctl lock-session"],
        "after_sleep_cmd": [
            "(kill $(pidof hypridle) || true) && (pidof hypridle || hypridle)"
        ],
        "ignore_dbus_inhibit": [False],
    },
    listener=[
        # Screenlock
        {
            "timeout": [300],
            "on-timeout": ["loginctl lock-session"],
        },
        # Suspend
        {
            "timeout": [600],
            "on-timeout": ["systemctl suspend"],
        },
    ],

Hey, regarding this workaround, do we know for sure if, "receiving a dbus post prepare_sleep event" as the wiki puts it, is triggered when the system goes into sleep mode or when it wakes up? I have yet to test it myself, but the wording of the description gives me the impression the command triggers when the system actually goes to sleep rather than when it comes out of sleep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants