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

[Pavel Machek]

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.

I believe power and suspend keys should definitely go through
input. I'm not that sure about battery... Lid is somewhere in
between...

> It's probably still the best option, though I argued for doing it the
> other way around - I want to know the pros and cons for all the possible
> approaches.

									Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/