lkml.org 
[lkml]   [2008]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: acpi/apm events as inputs: how to handle?
Date
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 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/

\
 
 \ /
  Last update: 2008-01-06 03:17    [W:0.051 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site