[ohm] monitoring INPUT state

[Richard Hughes]

On Fri, 2007-06-29 at 17:49 +0200, Nils Faerber wrote:
> Oh oh... probable misunderstanding here...
> I thought that it might be a good design decision to create first an
> idle plugin which will handle aggrgating data to decide if an idle
> state
> is reached and possibly which state of idleness.
> X11 and the input events would then serve as data input plugins for
> this
> idle module.

Yes, totally agree. See the current git structure where we have "glue"
and "policy". A plugin in glue would set a "system.idle 45" (seconds)
and a plugin in policy would do something. This lets us have clever
policy plugins like backlight that need several dependent sources.

> Else you might end up with two plugins that both measure idleness
> differently and have to decide one idle over the other - which is
> idler,
> X11 idle or input idle?

Only one would be running at the same time I would hope.

> It could be useful too to have both source activated but then you have
> to make a choice. 

How do you mean?

R.