Hi David, On Mon, Jan 07, 2013 at 12:58:23PM +0100, David Herrmann wrote: > EVIOCGKEYF returns the current keystate similar to EVIOCGKEY but also > flushes the outgoing evdev event queue. This allows user-space devices to > reliably retrieve the current state without having old events still in the > read()-queue. > > Userspace libraries like XKB/xkbcommon use stacking key trackers, so they > allow the kernel to map multiple keys to the same keycode. For instance if > left-shift and right-shift map to the same keycode, xkbcommon allows the > kernel to send key-down twice but also requires it to send key-up twice. A > single input device doesn't support that, but this is very useful if you want > multiple connected keyboards to have one shared modifier state: Pressing Shift > on the one keyboard affects keys on the other keyboard. This is not the usual > setup but it is supported and known to be used (for instance if you have > external num-pads etc.). > > When a program opens input devices, it can read the keystate via EVIOCGKEY > to update its internal keyboard state. This allows to keep CTRL pressed > while switching VTs and having both applications remember that CTRL is > still pressed. > However, if there are still outgoing events in the evdev queue, the > application will update its internal keyboard state and then read the > event again, even though it already processed it via EVIOCGKEY. > > EVIOCGKEYF solves this race condition by flushing the evdev queue while > returning the keystate. We cannot change EVIOCGKEY because we don't know > whether userspace depends on a clean read() history and flushing the queue > effectively drops events. > > This race could be fixed in user-space by keeping an exact copy of the keystate > array for each input device that we opened and ignoring double-events for a > single keycode. However, if we, as mentioned, want a shared keyboard-state, it > seems to be a waste of computing power and memory to keep another copy for each > input device if we could just use something like EVIOCGKEYF. I do not think we should introduce the new ioctl as I really doubt anyone is using it and even if they do I really doubt they will have problems if we flush the events. But rather that flushing all events we should only flush the key events. The relative, absolute, and other events should be kept in the queue. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
