>> https://bugzilla.redhat.com/show_bug.cgi?id=1579859
> Год с лишним спустя Status: NEW...Я сам не копал достаточно глубоко для понимания всего процесса, но если верить отписавшемуся там же Peter Hutterer (Senior Software Engineer @ RedHat)
> libinput doesn't do key repeats - it filters out the kernel repeats and only passes key down/up events on to the compositor. The key repeat you're seeing is the one triggered in the compositor (or Xorg but that's where this bug doesn't trigger) and is
> simply caused by gnome-shell being busy doing something else and thus not handling events as fast as it should.
и почитать апстрим-багрепорт https://bugzilla.gnome.org/show_bug.cgi?id=745032 (тоже "NEW" c 2015 года)
> we'll probably move libinput processing to its own thread (as
> is done on recent versions of Xorg) where it can directly update the
> hardware cursor without waiting for main drawing loop. This would probably
> involve moving the libinput backend from clutter to mutter, and adding
> mutexes shared by the KMS code and libinput backend. Doing this will not
> affect latency issues related to clients receiving input events; that'll
> require much larger changes, such as splitting up the shell UI into a
> separate process.
То ошибка в самом протоколе, вернее: в решении делегировать так же и "низкоуровневую" обработку нажатий клавиш клиентам.
Получается, что в случае иксов достаточно одной компоненты с повышеным приоритетом – даже если приложение не успевает обработать ввод сразу, то максимум будет начальный лаг при вводе, в случае обработки каждым клиентом заминка ччччччччревата более заметными последствиями.
