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,
