lkml.org 
[lkml]   [2006]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] [PATCH] Make ACPI button driver an input device
On 4/21/06, Yu, Luming <luming.yu@intel.com> wrote:
> >> > There are keyboards with power/sleep buttons. It makes
> >sense they have
> >> > the same behavior than ACPI buttons.
> >> Agree, make them behave like ACPI buttons -- remove them
> >from input stream, as they do not belong there...
> >
> >What if there is no ACPI? What if I want to remap the button to do
> >something else? Input layer is the proper place for them.
>
> If you define input layer as a universe place to all manual input
> activity,

Yes. If something is related to input it should be integrated into input layer.

> then I agree to port some type of ACPI event into
> input layer. But it shouldn't be a fake keyboard scancode,
> My suggestion is to have a separate input event type,e.g. EV_ACPI
> for acpi event layer.
>

The point is that it is not a fake scancode. There are keyboards that
have these keys that don't have anything to do with ACPI. That's why
they belong to input layer. The same goes for lid switch - we have
EV_SW that is used by some PDAs.

Note that I am not saying that other ACPI events, like battery status
or device insertion/removal, should be propagated through input layer.
But things that exist even without ACPI should not be ACPI-specific.

--
Dmitry
-
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: 2006-04-21 14:23    [W:0.055 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site