RFC: EV_SW support in xf86-input-evdev

[Peter Hutterer]

On Wed, Feb 03, 2010 at 01:46:00PM +0200, Rami Ylimäki wrote:
> 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.

most of evdev is developed on a need-to-need basis. EV_SW isn't supported
yet because no-one has expressed the need for it loud enough or written a
patch. (This generally applies to any missing evdev feature)

Matthew Garrett pointed out the need for switch events during the XI2
development cycle but they had to get dropped for lack of time on my behalf.
To me, the most striking difference between buttons/keys and switches is the
duration of the state. A button is temorarily down, a switch may remain in
a state indefinitely. This is important to clients, who will require an
approach based on state-polling more so than simply waiting for events.
Can't really comment on how much that'll really change in the clients
though, it may be trivial anyway.
 
> 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.

Note that assumptions that a device is limited to being a certain device
only has bitten us already, I'd say any assumption like this is likely to
cause headaches down the road.

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

This is likely to be the easiest, actually, especially since it avoids
long-term headaches. You need a protocol definition for the new events (if
they look the same as key events anyway you just need a typedef).
The device structure needs to be extended, together with a few new APIs.
However, that approach, unless you get it done really really soon, is
unlikely to land with server 1.9.

The question here is though that whether XKB support is needed for switch
events and if so - how that would look like. Aside from the XKB actions, XKB
also provides a "simple" way to reconfigure the meaning of a certain key,
for switches this may not be needed (I'm pretty sure a lid switch or camera
cover doesn't need language-specific configuration).
So this may be solvable by a simple hardcoded identifier table like
linux/input.h already uses.

Other interesting things here are the question how to send switch status to
the client, and enabling switch-based active and passive grabs. Hopefully
XI2 should scale there, I think it should support those without too much
effort.

Cheers,
  Peter

> 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?