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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Fri, 18 Feb 2005 14:26:51 +0100, Pavel Machek <pavel@suse.cz> wrote:
> Hi!
> 
> 
> > >> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> > >> > this option.
> > >>
> > >> That was written a long time ago before the new power management went
> > >> in.
> > >> On PDA's there is a power button and suspend button. So this was a hook
> > >> so that the input layer could detect the power/suspend button being
> > >> presses and then power down or turn off the device. Now that the new
> > >> power
> > >> management is in what should we do?
> > >
> > >Change power.c to generate power events like ACPI does, most likely.
> >
> >
> > There was some recent discussion of this on linux-input. It was basically
> > agreed that the input system should pass the request on to ACPI and/or apm
> > and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed
> > to be slightly modified to work with arm apm, the final result being:
> >
> > http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch
> >
> > I can confirm this works well on arm with apm enabled.
> 
> It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,

Yes, power.c is an aggregator that transports power events from the
input system into whatever power scheme is in use, so there will
always be a lot of ifdefs unless we will invent grand unified power
interface with userspace. I wonder if we could use kevents.

> and it will not work on i386/APM, anyway.

We could add fix i386 APM case but it looks like most people are
concentrating on ACPI.

> I still believe right
> solution is to add input interface to ACPI. /proc/acpi/events needs to
> die, being replaced by input subsystem.

There are many more events from ACPI that are not related to input, so
we need to keep it. Still, I can see buttons converted to input
devices which bind to power.c and then transmit requests to acpid
through /acpi/proc/event.

-- 
Dmitry