[ohm] monitoring INPUT state

[Rob Taylor]

Gross, Mark wrote:
> 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:
>>>> 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?

The new idle plugin interface has two keys, idle.state and idle.timeout.
idle.timeout is measured from the point of last activity. every time
idle.timeout milliseconds have passed since idle, idle.state is
incremented. This allows a policy plugin to have as many levels of
idleness as it requires, just changing idle.timeout when idle.state
increments. See policy/timeouts for an example.


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

Yes, that's exactly my take. In reality the kernel knows a lot more
about it than we do, so things like turning off devices should be done
there, depending on constraints we pass from userland. But it's gonna be
a while before the kernel gets a decent interface for this, so I think
for now a lot will happen at the userland level (and of course doing it
here should give some good ideas of what such a kernel interface should
look like)

>>>>> 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..
>>
> 
> From my perspective the way to inhibit various behavior is to specify
> acceptable use and wake up latencies per plug in.  

That sounds an interesting idea! Can you elaborate or give some examples
of how you see it working?

> 
> BTW: I'm very close to posting a kernel patch to put into place a QoS
> infrastructure that will enable usermode latency needs be communicated
> to the lower levels in a reasonable way.


Nice! do send me a pointer when you've posted it :)


Rob

> --mgross
> 
>> Thanks,
>> Rob
>>
>>> Thanks,
>>>
>>> --mgross
>>>
>>>> And this is just one example...
>>>>
>>>> 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
>>> _______________________________________________
>>> Ohm-devel mailing list
>>> Ohm-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/ohm-devel
>>
>> --
>> Rob Taylor, Codethink Ltd. -  http://codethink.co.uk


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk