RFC: EV_SW support in xf86-input-evdev

[Rami Ylimäki]

Hi,

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 
future.

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 
interfaces.

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,
Rami