sway: missed key events under high cpu load

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: <press key> and <release key>, but the program seems to just get the <press key> 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: sway version 1.4-9cda5a5b (May 7 2020, branch 'master')

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 2
Comments: 20 (7 by maintainers)

Most upvoted comments

I’m also experiencing this issue, on Sway 1.8.

viluon on Jan 24, 2023

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:

timeout 1 '' resume 'swaymsg "output * dpms on"'

When I stop swayidle, the problem no longer occurs.

If I do a check to see if the dpms on call is needed, the problem also does not occur:

timeout 1 '' resume 'swaymsg -r -t get_outputs | jq -e ".[] | select(.dpms==false)" >/dev/null && swaymsg "output * dpms on"'

I would have assumed (knowing nothing about sway’s code) that the output * dpms on command would be a NOOP if there are no screens that need to be turned back on but it seems whatever it’s doing is causing some lag.

FYI, the problem still occurs for me (and at a greater frequency) when using sway-git with CAP_SYS_NICE set on the binary with my original swayidle config.

JeffHenson on May 31, 2022

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.

v-gu on Sep 15, 2020

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 SYN_DROPPED event when it has to drop an event because userspace is too slow.

Quoting https://who-t.blogspot.com/2013/09/libevdev-handling-input-events.html:

A EV_SYN/SYN_DROPPED event is relatively recent (kernel 2.6.39). If a device sends events faster than userspace can read it, eventually the kernel buffers are full and the kernel drops events. When it does so, it sends a EV_SYN/SYN_DROPPED event to notify userspace. The userspace process then needs to stop what it’s doing, re-sync the device (i.e. query all axis, key, LED, etc. values), update the internal state accordingly and then it can start reading events again.

Incorrect SYN_DROPPED handling could be the cause here, but it isn’t sway or wlroots that handles this – it’s libinput, and libinput, to the best of my understanding, is supposed to replay events (or at least, not leave stuck keys?)

One possible way to confirm this (despite it being hard to reproduce) would be to run something like:

$ sudo libinput debug-events --show-keycodes /dev/input/event<your keyboard device> | tee ~/libinput-log

…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.

Xyene on Jun 6, 2020