>> >> > 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. Yes, it sounds reasonable. Then, at least, the user space Apps can rely on a single interface, and don't need to know the implementation details for the common input event. That will save a lot of support effort. > >> 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. ok. > >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. > I'm NOT sure if it is reasonable to propagate other ACPI events through input layer. But from my understanding, Laptop with ACPI features should be the super class of PDA. It would be nice to have input layer handle all ACPI events. Then, we can enjoy the advantage of a single input interface for user Apps. --Luming - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
