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,