lkml.org 
[lkml]   [2005]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6: drivers/input/power.c is never built
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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