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

[Dmitry Torokhov]

On Fri, 18 Feb 2005 19:39:36 +0100, Vojtech Pavlik <vojtech@xxxxxxx> wrote:
> On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote:
> > On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <vojtech@xxxxxxx> wrote:
> > > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
> > >
> > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > > > > > and it will not work on i386/APM, anyway. I still believe right
> > > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to
> > > > > > die, being replaced by input subsystem.
> > > > >
> > > > > But aren't there power events (battery low, etc) which are not
> > > > > input events?
> > > >
> > > > Yes, there are. They can probably stay... Or we can get "battery low"
> > > > key.
> > >
> > > We even have an event class for that, EV_PWR in the input subsystem.
> >
> > I really really think this is wrong. Power management should be
> > possible without input layer. EV_PWR is fine for telling input devices
> > to do something, like enter lower power mode
> 
> Definitely not for this. The request to go to low power mode should come
> from the other side - the bus the device lives on.

Probably not. On the other hand input layer is kind of a
hyper-transport allowing to send messages to several devices at one
regardless of the bis they are reside on.
  
> 
> > and for sending _some_ requests to the PM system.
> 
> I don't think input devices themselves should be sending any requests to
> the PM system at all, they should just pass the events to the userspace
> and have that decide what to do with it.
> 
> Maybe a simple event handler like power.c for transforming key events to
> power change requests for embedded systems makes sense, but normally
> many more variables need to be taken into account, and thus userspace
> needs to decide.
> 

I never said it should go staringt into the core of ACPI and
performing some action. That hack to power.c that I did was
effectively sending message to acpid giving userspace a chance to make
decision and react to the request.

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

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

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/