Date:   Sun, 04 Dec 2022 22:15:37 +0000
From:   ns@...no.gf
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Boyd <swboyd@...omium.org>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Bug: atkbd partially stops working after using raw input

Greetings,

The builtin keyboard on my laptop (a ThinkPad T480), which is driven by
the atkbd driver, can occasionally stop working after I use the
application prboom-plus[1] for a few minutes. As the title suggests, it
doesn't entirely stop working, but rather some keys like g, h, the up
arrow, & Escape (on ANSI QWERTY, & might be worth mentioning that it is
these keys specifically that get screwed up every time; maybe some
others I'm not aware of, but it's always the same ones) simply do not do
anything. The problem persists after I exit prboom-plus, in all
applications, including Wayland but also even fbcon & kmscon[2].

Sometimes the keys start working again practically randomly after some
30 minutes (average) of continued use of the machine after I have closed
prboom-plus. Why this happens is utterly beyond me. When it starts
working again I sometimes hold the key, & this results in my (very fast)
autorepeat being much slower than usual, which I think is an indication
of randomly dropped inputs. Whether I rapidly press a key or just give
it a single press every 5 seconds, it doesn't seem to make a difference
(basically just starts working again whenever it feels like it).

I use this machine for many hours at a time under Wayland (so libinput
for the input stuff), & I was not able to reproduce this without running
prboom-plus, ever. A reboot always fixes this issue, which is the only
consistent way of fixing it I've found; IOW if you run prboom-plus on
that boot, your keyboard is screwed the entire time until you reboot,
or if the keyboard is feeling in the mood to fix itself up (as detailed
in the last paragraph). So I'm somewhat convinced this is

  - a kernel issue
  - a problem that occurs when using raw input, which I imagine
    prboom-plus, an SDL2-based application, does.

Also, do note that evdev access is still mediated. Maybe I'm not using
the right terms for this, so what I mean is:

  % cat /dev/input/event4 # my keyboard
  coreutils: /dev/input/event4: Permission denied

Despite this, I don't think it's a problem with my userspace, because
again, it affects fbcon too, even when you kill any other userspace
using the input device.

Other notes:
  - I cannot trigger the bug immediately; you've gotta keep using
    prboom-plus for (AFAIK) at least 2m up to potentially 7m before it
    happens.
  - prboom-plus suffers from the bug just as much as every application,
    made very obvious when it becomes impossible to pause the game (yup,
    that's Escape not delivering any inputs)
  - other inputs like USB HID devices (USB keyboards, as well as USB mice
    & so on) are not affected by this at all; I cannot reproduce this bug
    with them even if I follow the reproducer entirely on the USB
    keyboard instead of the builtin keyboard. Well, precisely, the bug
    will still hit the builtin keyboard even though I didn't use it,
    but the USB keyboard's inputs will still be unaffected.
  - I have not been able to find a simpler reproducer yet; part of it is
    that it takes so long to hit the bug to begin with

Kernel version is c2bf05db6c78f53ca5cd4b48f3b9b71f78d215f1 on
torvalds/linux.git, but I can reproduce this bug even on mainline 5.19.

I can patch my kernel & tweak its configuration pretty easily, so I am
very much open to experimental patches & using testing subsystems to
obtain any information you might need.

[1]: https://github.com/coelckers/prboom-plus
[2]: https://github.com/Aetf/kmscon

Regards,

Powered by blists - more mailing lists