On Thu, Feb 05, 2015 at 08:28:28PM -0500, Benjamin Tissoires wrote: > On Feb 5, 2015 7:04 PM, "Dmitry Torokhov" <dmitry.torokhov@xxxxxxxxx> wrote: > > > > Hi Benjamin, > > > > On Thu, Feb 05, 2015 at 06:06:29PM -0500, Benjamin Tissoires wrote: > > > Hi Anshul, > > > > > > The commit 0c3e99437a66e4c869c60c2398449e6d98f3a988 in > dtor/input.git/next > > > tree introduce an interesting regression in libinput. The tests fail :) > > > > > > Actually, evemu-record and libinput switch the clock to monotonic when > > > opening an input node, and the first thing that gets queued is a > > > SYN_DROPPED event. > > > > > > However, in the libinput test suite, events are the bare minimum, and > > > most of the tests contain only one event set (one EV_SYN). > > > When seeing the SYN_DROPPED, the clients are supposed to drain the > events > > > until the next EV_SYN, and so they are losing the events that came long > > > after the ioctl call. > > > And in the end, the test suite does not receive any events. > > > > > > Removing the evdev_queue_syn_dropped() call in the ioctl handling fixes > > > the test suite, and Peter suggested that maybe we should queue a > > > SYN_DROPPED event iff there are events in the queue. > > > > Does the following patch fixe it? But I would like to see libinput > > tests more robust. > > It does. Thanks for the quick fix. > > Regarding libinput tests, I am not sure we could make them more robust in > this situation. The tests rely on uinput to create predetermined kernel > devices, with a known set of events. Usually, we test one feature/previous > bug we already seen in the past per device per test. The mentioned commit > changed the kernel behavior and I think there is no automatic way to detect > that the problem lies in the kernel rather than in the libinput event > processing. > > For example, the simplest test creates one mouse, waits for libinput to > open it, sends REL_X, EV_SYN, and ensures that libinput gets the REL_X > event. Without this fix, the event is not seen, so the test fails. Which is > right, because that means that any libinput client will see the first > events dropped. This is not something we want for our users, especially for > keyboards, when the first thing you do is typing your password for example. OK, fair enough. I'll queue the patch with your tested-by then. 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
