(Not so) recently, ACPI events started appearing as
key press events over linux input subsystem. The
question regarding this is simple: how it's supposed
to be handled?
First of all, I don't know any software so far that
can handle input layer in userspace when not running
X. In X, it's usually done using window manager
setup or with special application (like, volume
up/down keys etc). But without X, there's no such
application, as far as I can see.
It's easy to write one, but there may be.. issues
with finding which input device to use.
Now, linux already have hotplug subsystem, using
/sbin/hotplug helper (or whatever it points to,
or using netlink). ACPI key events are rare.
What I'm thinking about is: why ACPI events are
routed over input subsystem, instead of hotplug
subsystem? With input, there's a need for a
special daemon/application listening on the
specific "keyboard" device, while with hotplug
subsystem, it's already here - linux (by default
anyway, if not running udev etc), kernel fires
up a script when an event occurs. I don't see
how this special application/daemon is different
from ol'good acpid.
Or.. maybe I missed something?
Thanks!
/mjt
On Wed 2008-01-02 12:56:40, Michael Tokarev wrote:
> (Not so) recently, ACPI events started appearing as
> key press events over linux input subsystem. The
> question regarding this is simple: how it's supposed
> to be handled?
>
> First of all, I don't know any software so far that
> can handle input layer in userspace when not running
> X. In X, it's usually done using window manager
> setup or with special application (like, volume
> up/down keys etc). But without X, there's no such
> application, as far as I can see.
>
> It's easy to write one, but there may be.. issues
> with finding which input device to use.
>
> Now, linux already have hotplug subsystem, using
> /sbin/hotplug helper (or whatever it points to,
> or using netlink). ACPI key events are rare.
>
> What I'm thinking about is: why ACPI events are
> routed over input subsystem, instead of hotplug
> subsystem? With input, there's a need for a
> special daemon/application listening on the
> specific "keyboard" device, while with hotplug
> subsystem, it's already here - linux (by default
> anyway, if not running udev etc), kernel fires
> up a script when an event occurs. I don't see
> how this special application/daemon is different
> from ol'good acpid.
>
> Or.. maybe I missed something?
No, you are not missing anything. Yes, we could use /sbin/hotplug, but
it would be an ugly hack. So better write that daemon, or teach udevd
to read from input...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Michael,
On Wednesday 02 January 2008, Michael Tokarev wrote:
> What I'm thinking about is: why ACPI events are
> routed over input subsystem, instead of hotplug
> subsystem? ?With input, there's a need for a
> special daemon/application listening on the
> specific "keyboard" device, while with hotplug
> subsystem, it's already here - linux (by default
> anyway, if not running udev etc), kernel fires
> up a script when an event occurs. ?I don't see
> how this special application/daemon is different
> from ol'good acpid.
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.
--
Dmitry
[*] Embedded people are not particularly interested in
processing suspend requests in userspace and would rather
do it right in the kernel. I am about to apply a patch
from Richard Purdie that adds transaltion from input events
into APM events.
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.)
And by the way, what INPUT can one expect from a PC speaker?
input: PC Speaker as /devices/platform/pcspkr/input/input0
Thanks!
/mjt
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.)
>
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
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.
> And by the way, what INPUT can one expect from a PC speaker?
> input: PC Speaker as /devices/platform/pcspkr/input/input0
>
I ask myself about LNXVIDEO as well.
/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:13/LNXVIDEO:00/input/input3/event3/
Hi,
On Jan 7, 2008 8:03 AM, Andrey Borzenkov <[email protected]> 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
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.
Unless there's a way to multiplex the events...
(Hmm, this becoming quite... ugly. Oh well.)
By the way, where are all the capabilities of input devices
documented?
/mjt
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.
> 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... ;)
> By the way, where are all the capabilities of input devices
> documented?
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> ?
/mjt
On Jan 7, 2008 10:47 AM, Michael Tokarev <[email protected]> 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