On Thu, Feb 5, 2015 at 8:28 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> 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. > > Cheers, > Benjamin > Grmbl, sorry for the dup. Re-sending the mail not from the tablet which can not send the mail in plain text... :( Cheers, Benajmin -- 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
