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

[Vojtech Pavlik <vojtech@suse.cz>]

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

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