[ohm] monitoring INPUT state

[Gross, Mark]

>-----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.

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.  

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.


>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.

>
>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.
>
>> R.
>Cheers
>  nils faerber
>
>--
>kernel concepts GbR      Tel: +49-271-771091-12
>Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
>D-57072 Siegen           Mob: +49-176-21024535
>--
>_______________________________________________
>Ohm-devel mailing list
>Ohm-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/ohm-devel