[ohm] monitoring INPUT state

[Gross, Mark]

Sorry about the outlook text munging.  Comments below.

>-----Original Message-----
>From: Rob Taylor [mailto:rob.taylor at codethink.co.uk]
>Sent: Thursday, August 23, 2007 5:59 AM
>To: Gross, Mark
>Cc: Nils Faerber; ohm-devel
>Subject: Re: [ohm] monitoring INPUT state
>
>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: Monday, July 09, 2007 8:28 AM
>>> To: ohm-devel
>>> Subject: Re: [ohm] monitoring INPUT state
>>>
>>> Gross, Mark schrieb:
>>> [...]
>>>>> 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.
>>> And this xorg idle is bound to input devices which is IMHO pretty
weak.
>>
>> It would be good to drill down on what's weak about it, and try to
get
>> into a requirement definition mind set for the sub system's Ohm
depends
>> on.
>
>I've pretty much decided on using xorg idle for the default idle plugin
>- with the next release of xorg, X will listen to all input devices
>advertised in HAL.
>
>Of course, it's also plausible to do another idle plugin with the same
>interface that could, say, listen to all input devices directly.
>
>One thing I'd like to do, but still haven't, is to allow other plugins
>to signal user activity by setting idle.state to 0, but I haven't
looked
>into that yet.

Should idle.state == 0 (faulse) be non-idle and 1 be for idle?

>
>I think the right way forward for idleness of different subsystems is
to
>have sepereate idle plugins - so current 'idle' becomes only user input
>idle, and have network idle, audio idle, disk idle, etc.

I think this is a very good idea, but I have to wonder what user mode
could possibly do with a disk-idle or audio-idle event.  Yes, we would
turn-off the devices subject to some pre-defined wakeup latency
constraint.  What I'm wrestling with is where these actions belong, in
user mode or in kernel mode...  

Do we make the lower level subsystems idle aware and have them
auto-magically do these types of things, or do we force user mode to
deal with them?  I'm sure it will be a mixture of both, and user mode
will likely do it first and embarrass the kernel guys into doing it...

>
>>>> 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 know at least half a dozen of people near me that use this almost
>>> daily to read ebooks - an application renders the text and does
smooth
>>> scrolling. Ideally the spead is tuned to your reading speed so you
have
>>> a contiuous reading experience - quite convenient.
>>
>> Hmm.  I should try such a thing someday.  Perhaps someone could send
me
>> a pointer to such a reader off list?
>
>There needs to be a way for a user application to tell ohm to inhibit
>various behaviour. Usecases are media players, which would want to
>inhibit backlight (if playing video) and suspend (always), slideshows
>(backlight, suspend) and of course autoscrolling ebook readers..
>