On Mon, Jan 09, 2006 at 04:52:11PM -0500, Dmitry Torokhov wrote: > I probably was not clear in my original message. The new input handler > for ACPI would be only used for compatibility with cirrent > installations relying on ACPID. This will allow gradual conversion of > ACPI drivers to use input layer instead of sending events dircetly to > /proc/acpi/events.
Ah, I see what you mean. However, there's still some slight awkwardness here, since userspace will be expecting the events to come from the button driver (the regexp used is generally button[ /]sleep), and that'll be registered even if there's no sleep button (the lid switch and power button are still handled via it). I don't believe you can register two drivers with the same name, so without gross hacks I can't see an easy way to provide this functionality through /proc/acpi without requiring userspace to be fixed up /anyway/... > OTOH there should probably be anotehr generic power interface > filtering out power-related input events from the stream of all input > events in the system and making them available to userspace without > requiring applications (be it individual applications or HAL) to open > zillion of raw /dev/input/evenX devices. Sure. As mentioned before, we basically just want keycodes 116, 142 and 205 (POWER, SLEEP and SUSPEND) - I guess that's not too difficult? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
