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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel