Deactivate idle inhibitor programmatically

[adriangonz]

It would be good to have a way to active / deactivate the idle inhibitor module programmatically (e.g. from a CLI).

The use I have in mind is that whenever I lock my laptop, if I forget to deactivate the idle inhibitor on Waybar, it will just never go to sleep. Thus, it would be great for me if I could just deactivate it every time I lock my laptop.

I checked the source code, and it seems that this is currently implemented using something from wlroots? There may be some way to interact with that already, but I haven't found any.

[kmARC]

I'd love to see this nevertheless; My use cases would be:

• upon manual locking, I would like to disable the inhibitor for the future
• After 2 hours (or whatever longer period) I would like to get my screen locked anyways

Both these are needed since I "forget" that the inhibitor is on

[arnej]

I would also be interested in this.

My use case is: When I remove my YubiKey, I run several things. One of them is to run swaylock to lock the screen. When idle inhibitor is still active, the lock works fine, but the screen is never turned off. I would like to first disable the idle inhibitor before I lock the screen so that the screen could be turned off as if it was locked automatically.

[lunik1]

I would like something like this too, along with a way to trigger the idle inhibitor manually with a keyboard shortcut.

I thought one possibility for this would be to wait for a signal, but SIGUSR1 and SIGUSR2 are already in use...

[JohnMertz]

I'd also be very interested in this. My main concern is to be able to restore the idle state from the last time Waybar was running. I have a script to automatically reconfigure displays when I dock/undock and part of that involves killing and then load a different Waybar config. This always deactivates the idle_inhibitor and my memory is such that at least 80% of the time I end up getting swayidle notifications about impending locking before I re-enable it.

I'd just implement a fix for this by having an 'on-click' event which calls a script that writes the new state to text file, then after whatever process starts Waybar, I'd just have the state in that text file restored.

This is literally the only complaint I've had with the Waybar in a couple years of using it.

[nimitzpro]

@JohnMertz I'm currently starting and killing the swayidle process by running a script with on-click (which could extend to read/write to a file), but how do you restore state from the file back to waybar?

[JohnMertz]

@nimitzpro I hadn't had a way to restore the state from the file when waybar starts at the time I last replied. I was just joining the plea to have this issue addressed. However, since then I've basically figured out a workaround...

Technically I start swayidle and then never actually use the idle_inhibitor, I just change the idle behaviour based on the state stored in the file. It always starts with a list of actions, but depending on the state logged in the file, it will just ignore certain actions when the specific timeout is reached, up to and including not doing anything at all (effectively applying the idle_inhiditor by bypassing all idle actions).

Here's the shell script which starts swayidle, and executes each individual action and the script that is run by waybar to get the current state and rotate through the available idle states

Note: the sleep state doesn't work properly. It does not execute until swaylock is authenticated, then it shuts off the output and immediately comes back. 99% of the time I just use lock, so I've been too lazy to sort this out. The fade mode is also fairly boutique for my setup,

[coreyoconnor]

I wonder if this is the right place for programmatic idle inhibit. Should waybar, instead, reflect the current idle inhibitor lock state and rely on other wayland protocol clients to do the complex use cases?

The underlying wayland protocol: https://wayland.app/protocols/idle-inhibit-unstable-v1#zwp_idle_inhibit_manager_v1

does not have a way for an application to monitor the idle inhibitors. As far as I can tell anyways; I'm definitely not knowledable about wayland!

If that protocol did have a way then some of the programmatic change of idle inhibit could be separate applications. Waybar module would then listen for idle inhibit changes and reflect that state in the internal module.

[machitgarha]

Doesn't Waybar has an IPC option? So why not using it for this?

[nimitzpro]

I wonder if this is the right place for programmatic idle inhibit. Should waybar, instead, reflect the current idle inhibitor lock state and rely on other wayland protocol clients to do the complex use cases?

I have been able to alter the idle inhibit using a custom tab in waybar that changes a text file or runs a script, (used to use swayidle, now on hypridle).

I need to look into whether there's a way to show the current idle state if it has been altered by something else (e.g. a script, config, or macro). For example Hyprland auto inhibits sleeps when some windows are focused or active.