[ohm] monitoring INPUT state

[Richard Hughes]

On Fri, 2007-06-29 at 18:24 +0200, Nils Faerber wrote:
> For the idle usecase say... as a third source you could have a
> deliberate "unidle" source, i.e. an application could want to trogger
> the idle "watchdog" manually.

Yes, this will be similar to the Inhibit functionality we have in
gnome-screensaver (for inhibiting the screen) and gnome-power-manager
(for inhibiting the autosuspend).

> This would be a third source (i.e. X11,
> input/event/*, manual unidle). This could be useful for applications
> that want to prevent the system to perform idle actions - not very
> brilliant example since it could also disable the idle timer but then it
> could clash with the service that sets that values (which should be
> session settings?).
> A, good example: An ebook reader which does auto scrolling - the user
> does not make inputs but simply reads the book. Here you the X11 idle
> counter and the input/event would methods would fool you.

Sure, so in "glue" we have a plugin creating idle.time in seconds. We
then have another plugin called inhibit which exposes a dbus methods
Inhibit and UnInhibit and also creates activity.number_inhibited =
{clients}.

The display "policy" plugin can depend on both of those and do the right
thing when the number of inhibits is nonzero.

> I could also try to imagine other use cases where idleness is not always
> connected to input systems only and where it would be handy to be able
> to watch two or more sources of information.

Sure, look at the display policy plugin in git, i'm watching
ac_adpater.state and also lid.state to decide on the panel brightness.

Incidentally, the display policy plugin just sets the
backlight.percentage_brightness key, and lets a "glue" plugin actually
implement it. This keeps policy and hardware glue separate and lets us
have a "mesh" of different policies acting on many shared input sources.

Richard.