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

[Vojtech Pavlik <vojtech@suse.cz>]

On Fri, Feb 18, 2005 at 02:20:13PM -0500, Dmitry Torokhov wrote:

> > > But input layer shoudl not be used as a generic transport. I mean
> > > battery low, docking requests, etc has nothing to do with input.
> > 
> > Well, plugging in a power cord is a physical user action much like
> > closing the lid is, much like pressing the power button is, much like
> > pressing a key is.
> 
> What about power dying and my UPS switing on? I think it is out of
> input layer,

Yes, I was thinking about this, too. An UPS is pretty much the same
thing to a desktop as a battery is to a notebook. And I also got to the
conclusion that this is a bad idea.

But now that you are talking about this, I think there is some merit to
that way.

UPSes are usually handled by userspace daemons, either through serial
ports or via USB over hiddev (which is another driver that should be
redone from scratch). 

So we may need a way to loop these events through the kernel to make
them available to the power event handling software. uinput would be a
rather straightforward solution here ...

> we need PM/system state messaging layer. It can be based
> on acpi events and acpid or maybe kevents (but I don't like the idea
> of needing kobjects for that).

ACPI is too platform specific. We really need some platform independent
way to be able to have a simple software solution.

> Still power.c seems like the good place to hide all the ugliness and
> glue between that new (or old) layer and input layer.

Yes, it's a reasonable way. But the other way around (passing most power
related events through input) also is quite compelling.


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR