Evaluating 'system is idle'

[Marty Jack]

I bring this up because it has been on my mind for a while and this is a good opportunity to decide if we are doing what we want to and maybe improve the underlying mechanisms.

There are a number of things that happen if the system has been 'idle' for some period of time.  Different parts of the system use different definitions of 'idle'.

1.  The power state of the monitor can change.  This is mediated by the X server, which has the FD to the kernel driver that actually does the work.  The X server runs a timer that is reset whenever there is activity on an input device.

2.  The screensaver can trigger.  Same as above, only it creates an X event and maps a special window instead.

3.  The lock screen can trigger.  This tends to be implemented by overloading the screensaver mechanism.  If I remember my Orange Book correctly, this is a requirement for secure systems.  I do not still physically have my Orange Book so cannot look up if there is a definition of how the system idle determination is done.  It stands to reason that input activity would be appropriate, because the purpose is to help ensure that a system that has been walked away from cannot be accessed by someone walking by.

4.  The system power state can change.  Right now this is mediated by the power manager, which at least in some incarnations uses a measure of load average to decide that the system is idle.

5.  The system power state can also change when the lid opens or closes.  Right now this is mediated by the power manager but is peripherally interesting to Wayland because the lid event comes from an evdev device, which it could monitor like it does other input devices.

The problem with the load average computation is that the power manager wakes up a lot to evaluate it.  This costs battery power.  It seems like the kernel is in a very good position to offer a level triggered event when the load average goes above or below a specified value.  If someone were at Plumbers and had the right people around, this could be raised.  The lid switch tends to be evaluated by the power manager going directly at the event device, which sort of duplicates a lot of logic that the display server input layer has.

I guess the other question is, are we using the proper measure of 'idle' for all these cases.  Also, do we want to preserve the overloading of timed lock screen onto the screensaver mechanism.  And we also know there are cases where some of the power changes want to be inhibited for things like watching a video, so there needs to be a protocol for inhibiting.