On Wednesday, March 27, 2013 10:02:31 PM David Herrmann wrote: > 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? Yes, that is exactly what I mean, with the exception that flush should be selective. I.e. getting key state should not flush relative or absolute events and getting absolute state shoudl not flush key/bunnon events and so on. 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
