On Wed, Jan 31, 2018 at 10:18:14PM +0000, Tomasz Kłoczko wrote: > On 31 January 2018 at 22:09, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> > wrote: > [..] > > > Why I think that it may be related to libinput? Because in logs I see as > > well another type of entries: > > > > # journalctl -xe | grep libinput > > Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event5 debounce: offset negative (-354ms) > > Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event5 debounce short: offset negative (-368ms) > > Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event5 debounce: offset negative (-1107ms) > > Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event5 debounce short: offset negative (-1120ms) > > Jan 31 22:05:12 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event4 keyboard: offset negative (-331ms) > > Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event4 keyboard: offset negative (-750ms) > > Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error: > > libinput bug: timer event4 keyboard: offset negative (-413ms) timer offset bugs almost always mean that libinput_dispatch() isn't called quickly enough when its fd triggers. We rely on the compositor for that, so you can blame gnome shell here. Internally, libinput uses event timestamps and uses them for timers (e.g. tap timer, debouncing, etc.). Let's assume an event happens, our timeout is 150ms but it takes 500ms after the event before calling libinput_dispatch(), the timer offset is now 350ms in the past - that's what libinput warns about. It's not a killer but it does mean that whatever libinput was trying to do won't work correctly. In your case, the 'keyboard' timer is the one used in disable-while-typing. So expect that not to work correctly. Also: the keyboard timer is 500ms, and you have a neg. offset of 750ms. This is a delay of 1250ms, that's crazy! Something's hogging gnome shell here and it doesn't get to handle input. > Correction: > > # libinput list-devices | grep ^Device -A1 > Device: Video Bus > Kernel: /dev/input/event7 > -- > Device: Sony Vaio Jogdial > Kernel: /dev/input/event9 > -- > Device: Sony Vaio Keys > Kernel: /dev/input/event8 > -- > Device: Video Bus > Kernel: /dev/input/event6 > -- > Device: Power Button > Kernel: /dev/input/event1 > -- > Device: Lid Switch > Kernel: /dev/input/event0 > -- > Device: USB 2.0 Camera: USB Camera > Kernel: /dev/input/event13 > -- > Device: HDA Intel PCH Headphone > Kernel: /dev/input/event10 > -- > Device: HDA Intel PCH HDMI/DP,pcm=3 > Kernel: /dev/input/event11 > -- > Device: HDA Intel PCH HDMI/DP,pcm=7 > Kernel: /dev/input/event12 > -- > Device: Logitech M185 > Kernel: /dev/input/event5 > -- > Device: CD002 CD002 > Kernel: /dev/input/event3 > -- > Device: AT Translated Set 2 keyboard > Kernel: /dev/input/event2 > -- > Device: AlpsPS/2 ALPS GlidePoint > Kernel: /dev/input/event4 > > So event4 it is in my case touch pad and event5 it is Logitech M185 mouse. > In other words: those "libinput bug" log entries looks like are not related > to emitting those short bursts of repeating keystrokes. not directly, but they indicate where the issue is: key repeat is handled in the clients, not in libinput. With delays like this it's easy to see why you would get key repeat - if your key release event is delayed by 300ms or more the client will handle repeats before it gets the events. But the real cause of the issue is that you're getting crazy delays because gnome-shell is too busy with something else. The rest is fallout from that. Cheers, Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
