input devices handling

input devices handling

[Michael Tokarev]

[Repost for:
Message-ID: <48FF9737.5050207@msgid.tls.msk.ru>
Date:	Thu, 23 Oct 2008 01:12:23 +0400
To: linux-kernel@vger.kernel.org,
which is a repost of earlier message with similar
content/question, both went unanswered]

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

Re: input devices handling

[Dmitry Torokhov]

On Mon, Jan 12, 2009 at 11:19:20PM +0300, Michael Tokarev wrote:
> [Repost for:
> Message-ID: <48FF9737.5050207@msgid.tls.msk.ru>
> Date:	Thu, 23 Oct 2008 01:12:23 +0400
> To: linux-kernel@vger.kernel.org,
> which is a repost of earlier message with similar
> content/question, both went unanswered]
> 
> 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.
> 

You can either listen to hotplug events or poll (select)
/proc/bus/input/devices - waiters are woken up every time we
add or remove a new input device or a new input handler.

-- 
Dmitry

Re: input devices handling

[Michael Tokarev]

Dmitry Torokhov wrote:
[power/sleep buttons]
>> 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.
> 
> You can either listen to hotplug events or poll (select)
> /proc/bus/input/devices - waiters are woken up every time we
> add or remove a new input device or a new input handler.

Hmm.  Seems to be too much for a simple "power down when i press
`power' button' stuff.  Where the only thing needed is to run a
script when this button is pressed, but the code to watch for the
input device changes becomes larger and more complex than the
actual thing it should do.  (Maybe I stop somewhere at the middle:
scan all devices at startup and rescan when receiving a HUP signal,
or require a restart.  But the whole select-loop looks ugly too,
for such a simple task ;)

So this basically turns into another question being discussed in a
parallel thread: /dev/input/mice, /dev/input/keyboard, and maybe
/dev/input/event meta-devices...

Thanks!

/mjt