[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801052105.03068.dtor@insightbb.com>
Date: Sat, 5 Jan 2008 21:05:02 -0500
From: Dmitry Torokhov <dtor@...ightbb.com>
To: Michael Tokarev <mjt@....msk.ru>
Cc: Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: acpi/apm events as inputs: how to handle?
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists