Re: acpi/apm events as inputs: how to handle?

[Dmitry Torokhov <dtor@insightbb.com>]

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.