On 25/10/2018 19:01, Till Hofmann wrote:
On 10/25/18 4:47 PM, mcatanzaro(a)gnome.org wrote:
> On Thu, Oct 25, 2018 at 6:50 AM, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>> I get the same thing without any special load. System would work fine
>> for hours and then input would start bugging.
>>
>> It translates into floods of keystrokes, or eaten keystrokes, or
>> keystrokes being fed to apps out of order. Requires a system reboot to
>> fix.
>>
>> There is a serious bug somewhere in libinput WRT input queue
>> management (priorization, ordering, and press/release detection).
>>
>> I use Logitech wireless keyboards and mice with the bluetooth usb
>> dongle. Don't know if that's your case too.
>>
>> Regards,
>
> I don't think it's a libinput problem. I was talking with Alex about
> this a while back, and if I remember correctly, he thinks it's a Wayland
> protocol flaw: basically there's no way for the compositor to tell the
> difference between "the key is being pressed for a long time" and
"the
> computer is under such heavy load that the keypress end event hasn't
> arrived from the client yet". Of course it's a bit more complicated than
> that, but the end result is too many keystrokes, or eaten keystrokes.
> Something changed in F28 (or was it F27? recently at any rate) to make
> this bug occur way more often than it used to, and we're not quite sure
> what, but anyway, the problem is known to the relevant developers so
> hopefully might get fixed soonish.
>
> Hardware details aren't needed because it occurs for many developers on
> diverse hardware.
>
Where is this tracked so we can follow along?
There are a bunch of gnome bugs relating to it - try these:
https://bugzilla.gnome.org/show_bug.cgi?id=757942
https://bugzilla.gnome.org/show_bug.cgi?id=777693
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/