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

[Dmitry Torokhov]

On Jan 7, 2008 10:47 AM, Michael Tokarev <mjt@xxxxxxxxxx> wrote:
>
> Michael Tokarev wrote:
> > Dmitry Torokhov wrote:
> > []
> >>> 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.
> >
> > Ok, got it.
> > But I can't open the device multiple times, can I?
> > Like, there's a daemon listening on volume up/down and other
> > multimedia keys for example, and it can't listen to the same
> > eventX as a daemon that's watching for power/sleep buttons, --
> > instead, they should be combined into the same executable.

No, you can have as many readers as you want. Each of them will get
their copy of event so they can just ignore events they are not
interested in. There was a proposal to allow setting up a filter in
kernel to supress delivery of unwanted events but it is not
implemented yet.

> > Unless there's a way to multiplex the events...
> > (Hmm, this becoming quite... ugly.  Oh well.)
>
> Are the capabilities available over ioctl?  Because if not, it
> really is a problem to find correct /sys file for a given /dev
> node.  I'd rather not scan whole /sys to find the right device... ;)

Yes, they are available through ioctl.

>
> > By the way, where are all the capabilities of input devices
> > documented?
>

include/linux/input.h

> Looked at the code, but it's a bit... difficult to follow, so
> to say.  What is in ../capabilities/keys, for example - is it
> a bitmap of all keys the given event device can produce, based
> on KEY_xxx constants from <linux/input.h> ?
>

Yes.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/