[ohm] monitoring INPUT state

[Rob Taylor]

Rob Taylor wrote:
> Koen Kooi wrote:
>> Rob Taylor schreef:
>>> 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.
>> Xorg is of course installed on all headless systems, right?
> 
> A headless system can just use a different idle plugin, as I mentioned
> right below that line...
> 
> The case of a large multihead server is actually quite a bit more
> interesting, but I'm gonna ignore that usecase for now...
> 

*Actually* on a headless server you just need a different policy - you
don't care about user input, cos you have none, you care about network
activity.

Thanks,
Rob

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