> 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
> 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
event should have a timestamp when they were triggered (not when they were arrived)
if the trigger is older than X ms then do something special
On Thu, Oct 25, 2018 at 7:40 PM <mcatanzaro@xxxxxxxxx> wrote:
On Thu, Oct 25, 2018 at 6:50 AM, Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> 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.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
