Hi Dmitry On Sat, Feb 16, 2013 at 10:10 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > 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. (seems we have nearly the same delay for responses, sorry..) I'm not entirely sure whether I understand you correctly. Do you propose to just fix EVIOCGKEY to flush the queues? It does break semantics, but I agree, that this probably fixes existing userspace and does not break it. So if you agree, I will prepare a fix that flushes pending KEY-events for EVIOCGKEY. And I will try to do the same for ABS/REL events. And if you're too busy, I'll send it anyway ;) I'm also talking to XKB developers and it really seems that userspace already expects those semantics. I haven't found any application that expects the queues to report the duplicate events. But I'd really like to see this fixed. I hate knowing that there is a theoretical race-condition and I keep reminding myself of it.. Thanks David -- 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
