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

[Dmitry Torokhov <dtor_core@ameritech.net>]

On Friday 18 February 2005 18:31, Pavel Machek wrote:
> Hi!
> 
> > > What is the benefit of splitting the flow of information so?
> > 
> > It's split already. You get some from input (power and sleep keys on
> > keyboards, sound volume keys and display brightness on some notebooks),
> > some from ACPI events (power keys on notebooks and desktop cases, sound
> > volume, display brightness on other notebooks), some from /proc/acpi/*
> > (battery status, fan status), some from APM, from platform specific
> > devices, from hotplug, from userspace daemons (UPS status).
> > 
> > The question is how to unify it.
> > 
> > Using power.c to simply pass power/sleep keys to the ACPI event pipe
> > could get the input subsystem out of the loop at least. Maybe we could
> > even pass sound keys to it. 
> 
> I do not think passing sound keys through acpi is good idea. acpid
> does not know how to handle them, and X already know how to get them
> from input subsystem.

What X? I am not saying that sound events should go through acpid, but
why bringing X here? One may not even run X...

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

-- 
Dmitry