[lkml]   [2005]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6: drivers/input/power.c is never built

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?


Nigel Cunningham
Software Engineer, Canberra, Australia

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.079 / U:14.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site