RFC: EV_SW support in xf86-input-evdev
ext-rami.ylimaki at nokia.com
Wed Feb 3 03:46:00 PST 2010
It seems that xf86-input-evdev doesn't support EV_SW events yet. I'd
like to know if anyone has plans for adding the support in the near
future. Also it'd be nice if you could offer some insight on why the
support hasn't been implemented yet or how it will be implemented in the
First I'll describe an example problem that would require switch
support. I have a camera device that supports the following actions:
focus, shoot and lens cover adjust. The focus and shoot actions are
published as EV_KEY events (KEY_CAMERA_FOCUS, KEY_CAMERA) but the lens
cover is a switch and therefore published as EV_SW
(SW_CAMERA_LENS_COVER). All of these events originate from the Linux
gpio-keys device. It'd be nice to be able to handle these events on a
higher level without reading the kernel input device directly.
I've though about different solutions for this but it seems reasonable
to send the switch events as key events to clients. The main reason for
this is that is should be possible to remap the switch events to generic
keysyms for portability. A camera application would just handle key
presses that it is interested in without having to use any specialized
The main problem is that the keycode and switch-code spaces could
overlap, because the same input device is sending both key and switch
events. This means that there has to be a way to either separate the
code spaces or make a distinction between keys and switches. Some
possible solutions that come to mind are listed below.
1. Blindly convert switch events to key events and don't worry about the
overlap. Just assume that the input devices never send the same code as
EV_KEY and EV_SW in practice. Also create a custom keyboard mapping for
the device so that clients get whatever keysyms you want to use.
2. XKB starts to hopefully support high keycodes in the future. Add some
magical constant such as 1024 to the switch-code to transform it into a
keycode. Mapping to keysyms would be trivial and existing XKB interfaces
could be used. If the same device would attempt to send key events with
keycodes greater than 1024, those would be ignored as errors. This magic
constant could be a device specific configuration option.
3. The key event contents could be amended with some subtype flag to
tell whether the keycode of the events comes from a key or switch.
Alternatively some modifier key could be configured as a switch key and
would be turned on automatically for switch events. This is not a good
solution because by default the clients won't check for the subtype and
would just incorrectly handle switch events as key events. Also existing
XKB interfaces would need to be extended to accept an extra subtype
parameter so that mapping to keysyms would work correctly.
4. The most burdening approach would be to just introduce a new event
for switch state changes. This seems like a huge overkill as the switch
events aren't practically different from key events.
If you were to implement switch support in the near future, what kind of
approach would you take? Would it be sensible to just forget about this
kind of support in the X server for the time being?
Thanks for any insights,
More information about the xorg-devel