lkml.org 
[lkml]   [2005]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6: drivers/input/power.c is never built
    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@suse.cz> 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:4.791 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site