[ohm] monitoring INPUT state

[Richard Hughes]

On Mon, 2007-07-09 at 08:18 -0700, Gross, Mark wrote:
> 
> >-----Original Message-----
> >From: ohm-devel-bounces at lists.freedesktop.org [mailto:ohm-devel-
> >bounces at lists.freedesktop.org] On Behalf Of Nils Faerber
> >Sent: Friday, June 29, 2007 9:25 AM
> >To: Richard Hughes
> >Cc: ohm-devel
> >Subject: Re: [ohm] monitoring INPUT state
> >
> >Richard Hughes schrieb:
> >> 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.
> >
> >OK, great!
> >
> >>> 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.
> >
> >Hmm...
> >
> >>> It could be useful too to have both source activated but then you
> have
> >>> to make a choice.
> >> How do you mean?
> >
> >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. 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?).
> 
> This sounds scary to me.  We don't want to make the processor more busy
> when trying to save battery life buy running a busy loop daemon for
> kicking a watch dog looking for inactivity at the UI level.

Nothing should poll. Full stop. :-)

> I like the idea of an inactivity watch dog facility.  It would help to
> understand the different classes of subsystem inactivity one needs a
> watchdog on.  From this thread I see we only have xorg inactivity.  

Yes, but the idea being each could contribute a "idleness", and then the
policy plugin could then decide on the action.

> But, I can imagine: disk inactivity, audio inactivity, network
> inactivity, process inactivity, interrupt inactivity.  Where each
> "could" have a watchdog event go off to wake up some user mode process
> or kernel preference.

Sure, sounds very sane.

> >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.
> 
> Auto scrolling without user input?  That won't be too useable for me.

Agree. My reading time is proportional to complexity of the text being
read :-)

Richard.