Re: 2.6: drivers/input/power.c is never built

[Nigel Cunningham <ncunningham@cyclades.com>]

Hi.

On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: 
> On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > I believe power and suspend keys should definitely go through
> > input. I'm not that sure about battery... Lid is somewhere in
> > between...
> I think we need a generic way of delivering system status changes to
> userspace. Something like acpid but bigger than that, something not
> so heavily oriented on ACPI. I wonder if that kernel connector patch
> should be looked at.

Absolutely. I've been thinking about this too, but haven't yet found the
time to put it down on paper/email yet.

I think we need a very generic system by which changes in anything 
remotely impacting on power management (kernelspace or userspace,
including ACPI, UPS drivers, keyboard handlers, devices etc) can notify
events to a userspace daemon. This daemon can act in accordance with
user specified policies (changeable on the fly) to implement system
level state changes (suspend to ram/disk, shutdown etc), run time power
management (shutdown a USB hub that just signalled the removal of its
last client), logging and so on. In some cases, it might set policy but
not be actively informed of the details of the application of that
policy (we don't feedback loops with a process leaving C3 to notify that
it's entering C3!).

This implies, of course, not just a generic way of notifying changes,
but a generic way of implementing policy.

Sound too ambitious, or am I thinking your thoughts after you?

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574