[ohm] monitoring INPUT state

Rob Taylor rob.taylor at codethink.co.uk
Thu Aug 23 05:58:38 PDT 2007


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.

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.

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

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


More information about the Ohm-devel mailing list