[ohm] monitoring INPUT state

Gross, Mark mark.gross at intel.com
Mon Jul 9 09:20:46 PDT 2007



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

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

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


More information about the Ohm-devel mailing list