[ohm] monitoring INPUT state

[Rob Taylor]

Koen Kooi wrote:
> Rob Taylor schreef:
>> 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.
> 
> My headless devboards have a huge array of buttons, leds and optional 7-segment or 20 char
> lcds, but still no xorg.
> 

Right, that's not a headless server.

The way I'd recommend to handle such a case would be to have those
buttons exposed in the kernel input layer, and write an idle plugin that
listens for hal devices with the 'input' capability, selecting on their
devices to watch for activity. I'd like to see such a 'hal-idle' plugin,
but it's not something I'll be doing any time soon, I think.

The point being, you will generally derive user input activity from
/dev/input and so only one input plugin is needed at a time, either
using xorg's IDLETIME counter which does the work for us and guarantees
a parity between what the user sees as input and what ohm considers
input, or by doing the same thing as outlined above.

Having a way for other plugins to signal some activity outside of this
main input helps with fringe cases e.g. devices that incorrectly don't
expose input in the kernel input subsystem or that are handled in user
space (again, still not much of an excuse not to use the kernel input
subsystem - e.g thinkpad-keys).

Thanks,
Rob

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