[lkml]   [2005]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6: drivers/input/power.c is never built
On Fri, Feb 18, 2005 at 10:23:19PM +0100, Oliver Neukum wrote:

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

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

> > I think that's all you need to trigger actions. You don't need the exact
> > percentage of the battery, and you don't need the exact AC voltage at
> > input.
> That is very debateable. I might want a quiet mode and would be
> interested in notifications about thermal data and fan status.
> Regards
> Oliver

Vojtech Pavlik
SuSE Labs, SuSE CR
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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean