On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote: > On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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. > 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. > 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. I definitely wouldn't want to see input to be a generic trasport layer - it is not. But I wouldn't be opposed to pass some of the user induced events through it. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
