Messages in this thread | | | Date | Fri, 21 Apr 2006 08:21:03 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: [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/
| |