mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: "Michael Tokarev" <mjt@tls.msk.ru>
Cc: "Andrey Borzenkov" <arvidjaar@mail.ru>, linux-kernel@vger.kernel.org
Subject: Re: acpi/apm events as inputs: how to handle?
Date: Mon, 7 Jan 2008 10:51:28 -0500	[thread overview]
Message-ID: <d120d5000801070751u29111a75kf52d5cfcc00c94@mail.gmail.com> (raw)
In-Reply-To: <4782497B.2050306@msgid.tls.msk.ru>

On Jan 7, 2008 10:47 AM, Michael Tokarev <mjt@tls.msk.ru> 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

      reply	other threads:[~2008-01-07 15:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-02  9:56 Michael Tokarev
2008-01-05 23:30 ` Pavel Machek
2008-01-06  2:05 ` Dmitry Torokhov
2008-01-07 10:42   ` Michael Tokarev
2008-01-07 13:03     ` Andrey Borzenkov
2008-01-07 14:20       ` Dmitry Torokhov
2008-01-07 14:50         ` Michael Tokarev
2008-01-07 15:47           ` Michael Tokarev
2008-01-07 15:51             ` Dmitry Torokhov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d120d5000801070751u29111a75kf52d5cfcc00c94@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=arvidjaar@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®