Messages in this thread | | | From | Andrey Borzenkov <> | Subject | Re: acpi/apm events as inputs: how to handle? | Date | Mon, 07 Jan 2008 16:03:39 +0300 |
| |
Michael Tokarev wrote:
> Dmitry Torokhov wrote: >> Hi Michael, > > Hello! > > [] >> 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. > > Aha, this makes sense. > And it brings a few questions, too. > > As far as I can see, there's little information about how to > actually use the input interface. Let's suppose I'm about to > write an application (a daemon) that should replace acpid -- > it's handling of the said buttons (power and sleep). How to > find the right devices? Should it use /dev/input/event* or > something else? How about handling hot-plugged devices like > new (and removed) keyboards? (And yes, my keyboard has a sleep > button.) >
Well, you use event device in any case; as for finding right one - I guess you look at device capabilities and filter what you need ...
{pts/0}% cat /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/capabilities/key 100000 0 0 0
you could also check name but I guess it is unreliable
{pts/0}% cat /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/name Power Button (FF)
Then you have your event device:
{pts/0}% ll -d /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1 drwxr-xr-x 3 root root 0 2008-01-07 15:32 /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1/
the problem that you *really* have - nobody prevents user from using udev to renaming /dev/input/event1 away into anything (s)he likes. Of course you could do
{pts/0}% udevinfo --query=name --path /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1 input/event1
.. but at some point we have to commit to support this interface forever.
> And by the way, what INPUT can one expect from a PC speaker? > input: PC Speaker as /devices/platform/pcspkr/input/input0 >
I ask myself about LNXVIDEO as well.
/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:13/LNXVIDEO:00/input/input3/event3/
| |