my first email to the xfree86 ML about it (from June 2005).
The kernel should provide a device file from which timestamped keyboard events are read. It should also provide a way to distinguish from which physical keyboard the event came, for example by providing distinct device files.
New: I relaxed the requirement for timestamping. If the kernel provides monotonic timestamps (and also the monotonic time via clock_gettime CLOCK_MONOTONIC) these will be used, otherwise we use the usual way used in X server. That means calling GetTimeInMillis.
Which kernels provide such device(s):
The driver manages a set of keyboards devices as one logical keyboard. That means that X clients see one core keyboard. It is a different approach from XInput (that would expose several X keybords to clients, and let them choose from which to get events).
Handling more file descriptors is unusual (for an input driver), so I cannot use a standard, relatively high level API: xf86AddInputDriver and xf86Wakeup but I have to use lower level RegisterBlockAndWakeupHandlers to work more closely to the Select() code, and look directly at the select mask to see which of the managed file descriptors have input ready.
Of course, given that now the events are delivered timestamped, I had to extend the interface code --- xf86PostKeyboardEvent function.
As a protection against losing keyboard, medved uses polling, to discover /dev/input/eventXX files.
When I read about hal I might implement another way.
Imagine that an application which obtained a "keyboard grab", stopped accepting key events (i.e. it holds a synchro grab and doesn't call XAllowEvent). If You want to steal it, or close that X client, you need a special key.
If the special key depends on the XKB state, and the XKB state depends on the whole sequence of previous keys, and might depend on calls from the blocking application, you ask for too much.
Example:
Let's assume, the current (frozen) state is not "meta & control modifiers". When you press 3 keys Control Meta and kp-/, the first 2 events enter a queue; when the keyboard driver sees the 3rd key (kp-/) it will look at the XKB state which is not modified (b/c events on the queue are not processed in any way, b/c of the grab) and therefore -- as assumed -- is not "meta & control modifiers", hence it will not trigger any special function.
Medved does not look at the XKB state. It looks at combinations of simultaneously pressed keycodes.
This solves the following bugs:
[0] medved = bear in czech language. And it is similar to (multiple) evdev. I like it.
[1] unfortunately even the kernel provided timestamp is not good enough, in current version. On notebooks w/ slow harddisks for example. The hard-disk interrupt handler has precedence. But, the input event (irq) handler doesn't get the timestamp at the beginning (as i would need) --maybe that can improve. So, If hard disk is a lot active the auto-repeat is not reliable. This needs more knowledge on kernel than what i have now.
[2] Medved is a (logical) OR combinator: each keycode is pressed if and only if any of the keys with scancodes mapped to that keycode are pressed.