From: Michael Tokarev <mjt@tls.msk.ru>
To: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: input devices handling
Date: Thu, 23 Oct 2008 01:12:23 +0400 [thread overview]
Message-ID: <48FF9737.5050207@msgid.tls.msk.ru> (raw)
Hello.
Similar question has been asked already by me in the past,
regarding "conversions" of ACPI button events to "keyboard
events". The talk is about how one is supposed to handle
various "common" "meta-buttons" like Power, Sleep, and so
on.
Before, there was /proc/acpi/event and /etc/acpid/* stuff,
and it was easy (but somewhat clumsy) to act to system power
down button. But the "proper way" now is to handle
/dev/input/event* interface, because such "Power" button can
be on a keyboard, on a remote control, and so on. I understand
the idea, and I like it.
But now the question. How one supposed to find all the devices
which generate such events? I mean not about scanning the /dev
directory, which can be done once at startup, but about REscanning
it to find which NEW keyboards and the like appeared since last
(re)scan and which were removed.
For mouse, there is /dev/[input/]mice, which is a meta-device
for all mouse-like devices out there, and it actually works.
For an application that reacts to system button events, there
is no such device, and the only way is to scan all keyboard-like
devices and open them all (well, only ones which actually have
the buttons in question, but that's minor detail).
So now I have to know WHEN to (re)scan the devices. Should I
depend on udevd/hald for that (i really dislike this way)?
Or should I just rescan periodically, say, every 10 sec or
so? Or is there other, better way?
The only thing I need so far is to be able to shut down the
machine on a power down button. Maybe in the future something
like changing audio volume etc will be of interest too, but
that should be pretty similar.
Thanks!
/mjt
next reply other threads:[~2008-10-22 21:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 21:12 Michael Tokarev [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-01-12 20:19 input devices handling Michael Tokarev
2009-01-13 5:47 ` Dmitry Torokhov
2009-01-14 13:32 ` Michael Tokarev
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=48FF9737.5050207@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.