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

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

Hi,

On Jan 7, 2008 8:03 AM, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> 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.)

I think the best ways is to listen to hotplug events in some fashion.
Raw netlink, D-Bus, etc.

> >
>
> 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
>

Exactly. Any driver working through evdev interface should examine
device's capabilities and decide whether it is interested in the
device or not.

> 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.
>

/sys/class/input/event0/device pointe to corrseponding input device
and you can get capabilities from there.
/sys/class/input/event0/dev contains dev_t so if you don't see proper/
/dev/input/eevent* you can create your own.

> > And by the way, what INPUT can one expect from a PC speaker?
> > input: PC Speaker as /devices/platform/pcspkr/input/input0
> >

Speaker is tied very closely to keyboard beeps and that's why it is
part of input system.

>
> I ask myself about LNXVIDEO as well.
>
> /devices/LNXSYSTM:00/device:00/PNP0A03:00/device:13/LNXVIDEO:00/input/input3/event3/

There are keys that are tied in firmware to the video device that
switch between CRT and LCD on laptops. They emit events like
KEY_SWITCHVIDEOMODE and so input device was needed.

-- 
Dmitry