Hi Michael, On Wednesday 02 January 2008, Michael Tokarev wrote: > What I'm thinking about is: why ACPI events are > routed over input subsystem, instead of hotplug > subsystem? With input, there's a need for a > special daemon/application listening on the > specific "keyboard" device, while with hotplug > subsystem, it's already here - linux (by default > anyway, if not running udev etc), kernel fires > up a script when an event occurs. I don't see > how this special application/daemon is different > from ol'good acpid.
There are keyboards (USB, PS2) with Sleep and Suspend buttons that are not related to ACPI nor APM. We had 2 options - add an input handler that would translate input events into ACPI events and feed /proc/acpi/event[*] or go other way around and use input layer for delivering suspend and sleep requests for all types of keyboards/buttons, including ACPI buttons. The secons option is better because userspace solution using input layer will not be tied to a particular technology (ACPI) and can be used on other platforms as well. -- Dmitry [*] Embedded people are not particularly interested in processing suspend requests in userspace and would rather do it right in the kernel. I am about to apply a patch from Richard Purdie that adds transaltion from input events into APM events. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
