missed key events under high cpu load #5423
Comments
|
I believe I have experienced this too, but as stated, it is hard to reproduce reliably. |
|
I don't think sway/wlroots can drop events like that. From the sound of it the key press is being handled, but a release is never seen so sway starts repeating. In general though, you're right: it is possible for events to be missed due to high CPU usage, but it'd be userspace (not the kernel) missing them, and they're not supposed to be dropped silently. The kernel generates a Quoting https://who-t.blogspot.com/2013/09/libevdev-handling-input-events.html:
Incorrect One possible way to confirm this (despite it being hard to reproduce) would be to run something like: ...when you think you're going to be doing something that has a chance of reproducing the issue. Note, of course, that this is a keylogger (but that probably doesn't matter if you're playing games?) Then, if we were to see that the logs contain consecutive pressed events for the same key, with no release in-between, we'd know that the issue would be in libinput. Otherwise, it's in sway/wlroots. |
|
I will give it a shot today or tomorrow evening. Edit: |
|
I don't think so, but you should be able to see them through something like |
|
Ok, some results: Atleast for one particular game (eco) that had a very erratic behavior concerning my keyboard (basically missing out on keyevents all the time) I found the problem in the output of dmesg. While in game the dmesg output got spammed with the message I will still keep the keylogger running when playing some other programs that also seem to sometimes miss key events and see if its the same problem for other programs. What I would be interested in, does anyone have an idea why the usb device is reset all the time or how I could pin this down? |
|
It's possible the kernel is trying to put the USB port into an idle, low-power state, and the hardware doesn't like it, resulting in a disconnect and reconnect. If that's the case, it's fixable with an udev rule. The other possibility could be some sort of physical break in a cable/circuit somewhere, or some other miscellaneous USB issue. |
|
But why would that happen when a specific program is running? |
|
Glad you figured out a workaround! If you don't mind though, it would be useful to dig a bit deeper here, since regardless of flaky hardware we really shouldn't be leaving keys stuck. If you modify the logging command to: what I'd be interested in seeing is if you see I've tried reproducing this issue locally by:
but all of these result in the device being removed / re-added gracefully, and sway notifies clients that keys have been released when a keyboard is removed. |
No problem :) All the logs I gathered (dmesg, sway, evemu, libinput): All logs are from the same session, each line appended with the timestamp when it got into the pipe (it seems libinput buffers a few lines when outputting into a pipe?). The interesting time stamps can be easily found by looking at the last few lines in the dmesg output (for example
Also I tried reproducing the problem in xfce4, with success, so this might not be a problem of sway at all.. Tomorrow I will also add a log from the kernel debug fs usbmon with correct timestamps including the other logs, but as a small teaser some outstanding lines from the output: Whats interesting is, those long lines don't seem to appear usually, but only when in the game and having a "stuck" key. I might try and find out what they mean tomorrow (maybe its just the reset of the usb device, but not the cause?) |
|
Great!
Yeah, this is standard behavior of many applications that you can disable by
Hmm, which keys got stuck during this trace? Overlapping the timestamp you mention shows: Was left Alt the key that got stuck? Also, for clarity purposes: do these keys "unstick" themselves (e.g., after the USB bus finishes resetting)? How do you stop them from repeating? |
|
It was the w and s keys (multiple times). The keys only "unstick" after pressing another key. New day, new session, new logs :) (For some reason the sway log was empty, I guess I misused the unbuffered there, sorry)
The relevant timestamps from the logs should therefore be around the last time I "released" "w" and pressed "s": (For clarity: no I did not release w and press s within a fraction of a second, I actually released w before that, but the "key event" is only generated upon pressing the "s" key) The timestamp of the dmesg line howerver matcher the "long" lines in the usb-log (if anyone can read them). For completeness here are the commandlines used to get the logs: (I tested all and none of them appeared to buffer anything, except the dmesg one which I don't know how I could test (but I think it doesn't buffer)). |
|
I experience this is for a long time, regardless of log details, I tried with Xorg, same Unity3D game, no key stuck issue, in sway, it has. |
|
https://gitlab.gnome.org/GNOME/mutter/-/issues/532 looked the same? except it's mutter |
|
My test rest: In following session, key stuck happened for 2 times(I'm just walking left(A) and right(D) in-game), but nothing suspicious printed, only before game launch, Here when I lift Although in the output |
|
The same issue. Xorg with libinput works fine. |
|
Have this issue too. |
|
#6994 should fix this if your sway binary is started with |
|
I was having what sounds like the same issue while playing games (with some screen lag when it happens) but I think I've narrowed down what my problem is. I'm pretty sure my issue was being caused by this setting I have in swayidle: When I stop swayidle, the problem no longer occurs. If I do a check to see if the I would have assumed (knowing nothing about sway's code) that the FYI, the problem still occurs for me (and at a greater frequency) when using sway-git with |
|
I'm also experiencing this issue, on Sway 1.8. |
|
Having a similar issue with mouse events being missed, (keyboard events are unaffected), during specific high loads. I can reproduce reliably using by generating a procedural map in ARK: Survival Evolved. This causes me to miss key events in Steam, flatpak librewolf (with forced x11), and xterm. All native wayland applications are unaffected. For me at least, issue likely involves xwayland. libinput debug-events --show-keycodes also shows the mouse buttons always being captured in the keylogger, so I don't think it's an issue with libinput. Artix Linux, Kernel 6.6.2-artix1-1 |
|
I just started noticing this bug, Keyboard input is kind of important, why is this not a high priority bug? |
When under high cpu load, the focused window sometimes does not get key events.
The problem is kind of hard to reproduce reliably but it occurs to me mostly while playing games but also in alacritty while some cpu intensive stuff is going on in the background.
Most of the time I observe it as: and , but the program seems to just get the part and starts to repeat the pressed key.
Now I'm not sure if this is an sway bug at all or just linux missing out usb stuff due to high cpu usage, but I couldn't find anything indicating this happens in a quick google search.
sway version 1.4-9cda5a5b (May 7 2020, branch 'master')The text was updated successfully, but these errors were encountered: