Keyboard input "sticking" on GNOME at low FPS

[SilverStraw]

I've encountered an issue where keyboard input will "stick" in games running on Proton. This means that if I hold a directional key for a few seconds the input will persist for some time after releasing. This issue is way more apparent when the framerate is lower. It's imperceptible when the game is running at 120+ fps, somewhat perceptible when running at 60 fps, and extremely apparent at 30 fps. At 30 fps the input will persist for multiple seconds.

Proton 6.3-7 and Proton - Experimental are affected by this. Older versions that are available in Steam (<=5.13.6) are not. In GloriousEggroll's build of Proton this issue seems to have been introduced between 6.5-GE-1 and 6.5-GE-2.

This seems to be an issue that happens only on GNOME. I'm currently on Ubuntu 21.10 (GNOME) where this occurs. I tested on Arch+KDE and on Arch+Sway and it didn't occur on either. It's not exclusive to my setup/hardware because it occurs on both my PC and my laptop.

It doesn't happen in every game. So far I've experienced it in: Portal 1, Race the Sun, Jump King, Far Cry 5, and Here Comes Niko. Spyro Reignited Trilogy is one game I've seen so far where it doesn't happen. To clarify: this only happens in Proton. Portal 1 running through Proton is affected but the native version is not.

Only keyboard input is affected. Using a dpad on a controller does not produce this behavior. Modifier keys on the keyboard (like CTRL and SHIFT) are not affected either.

[alvarlagerlof]

I can confirm that this has started to happen for Dirt 3 too. Quite ruining the experience.

Edit: Dirt Rally 2 too. I am on Fedora Silverblue 35 on 495.44 using Steam in a Flatpak (which as worked amazing until now).
Edit2: I have confirmed that the proton version starting at 5.x currently listed does not have this issue.

[mmarsalko]

This occurs with game controllers, as well. When playing Guilty Gear Strive, my left input frequently gets eaten if I press right shortly beforehand (milliseconds apart). Left will remain stuck un-pressed until I release and press again. Reverting to Proton 5.13-6 resolves the issue.

[CrystalSplitter]

Can also confirm this, reverting to Proton 5.13-6 resolves the issue for me. GNOME on both PopOS and Ubuntu (tested both 20.04 and 21.10).

[youkwhd]

I can confirm this, was tested using proton experimental and 7.0-1, games that i was playing was: Euro Truck Simulator 2, and CarX Drift Racing. I'm on Arch (dwm / i3-gaps).

[kirill-fedyanin]

I had same thing; in my case it was repeating keys (i prefer small delay / fast repeat setting). I just disabled it in settings -> accessibility -> repeat keys and everything seems to work ok now.

[Pockets-byte]

same issue on proton next and experemental. arma 3, fedora, iris xe and i7

[romulasry]

Same issue: Fedora Rawhide.

[romulasry]

Here is the bug I get on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2174962

[notpeelz]

Here is the bug I get on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2174962

Is this even related? I'm also using ibus and I'm not getting these errors.

Edit: just to be clear, I'm also having the input problems, although it doesn't seem to be related to low FPS in my case.

Running Steam in flatpak.
Proton: Experimental
Distro: Arch
DE: GNOME 43.3 w/ ibus enabled

The issue occurs with and without extensions enabled.

[romulasry]

Here is the bug I get on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2174962

Is this even related? I'm also using ibus and I'm not getting these errors.

Edit: just to be clear, I'm also having the input problems, although it doesn't seem to be related to low FPS in my case.

Distro: Arch DE: GNOME 43.3 w/ ibus enabled

The issue occurs with and without extensions enabled.

Yes, I get it on Fedora Rawhide when playing Steam Proton games.

[notpeelz]

Yes, I get it on Fedora Rawhide when playing Steam Proton games.

What I'm saying is, how can you be sure that this ibus crash is related to the "sticky input" problem? I'm also getting the sticky input problem, yet no ibus errors.

[romulasry]

Yes, I get it on Fedora Rawhide when playing Steam Proton games.

What I'm saying is, how can you be sure that this ibus crash is related to the "sticky input" problem? I'm also getting the sticky input problem, yet no ibus errors.

Because it happens right when the keys go bad and I have to alt+tab to fix it.
What version of ibus are you using?

ibus-1.5.28 here.

[notpeelz]

Arch also distributes ibus 1.5.28 at the moment. I've only noticed it happening with my WASD keys. One of them will get stuck and I have to press W/A/S/D again to fix it.

[romulasry]

Mine does it for the keyboard in general, keyboard left,right, up and down arrow keys as well.

[notpeelz]

Mine does it for the keyboard in general, keyboard left,right, up and down arrow keys as well.

I haven't been playing many games recently, but I don't remember noticing input issues like this since I switched away from Windows on my gaming rig. I only really play FPS games where most of my keyboard inputs are WASD. I'm assuming that's why I haven't noticed any other keys getting stuck.

I played all of Resident Evil 8 last month with no issues. Last week, I started playing Resident Evil 2 and, just now, a bit of Deep Rock Galactic. My movement keys (WASD) would get stuck very often. Not sure what changed.

[romulasry]

Gnome 44.beta Wayland Linux 6.3.0-0.rc0.20230303git2eb29d59ddf0.13.fc39.x86_64

Xwayland 23.0.99.901

[notpeelz]

Seems like I managed to fix my input issues (for now?). I uninstalled ibus and all of its dependencies, disabled all my GNOME extensions, switched to Proton 7.0-6 (instead of Experimental) and rebooted. After playing a couple games of DRG, it seems like that did the trick. I re-enabled my GNOME extensions and it stills seems to work correctly.

I will update this post if the issue comes back.

[romulasry]

Sounds like a problem in ibus, no?

[notpeelz]

Can't say for certain, but ibus seems to be the most likely cause. It was working fine previously, not sure what changed. The last update to the Arch ibus package is from 2023-02-21 (nearly 2 weeks ago)... or maybe I did something to my system since I last played games? (I tend to tinker a lot)
I'll have to do some more testing gaming to know for sure.

If this is a recent problem with ibus, this is most likely not the same issue that was originally reported.
Now that I'm re-reading the original bug report, I realize that it doesn't quite match what I'm experiencing:

This means that if I hold a directional key for a few seconds the input will persist for some time after releasing.

My W/A/S/D inputs get stuck (seemingly) permanently until I press them again, not temporarily like the original bug report describes.
Which one are you experiencing?

Edit: my inputs could could very well only be stuck for a couple seconds, but I never waited to see if it would resolve on its own 😅 My issue doesn't seem to be related to low FPS either.

[romulasry]

Mine get stuck until I alt+tab.

[eternal-sorrow]

I don't use iBus and Gnome but I get the sticking keys problem. FPS does not matter, I get it even in simple 2d games sometimes.

[notpeelz]

@romulasry @eternal-sorrow Wayland or X? And what DE/WM?
I use GNOME 43.3 on Wayland.

[eternal-sorrow]

Wayland, sway.

[romulasry]

@romulasry @eternal-sorrow Wayland or X? And what DE/WM? I use GNOME 43.3 on Wayland.

Same but I get the same bug on X as well.

[LRitzdorf]

I seem to have the same issue as @notpeelz, and it's showing up in DRG for me as well. (I don't play many other games, so I can't test extensively.) In my experience, the relevant key is continually detected as pressed until I tap it again.

I do have IBus running, so I'll try killing it and check whether that resolves the issue for me.

(Edit: running i3wm on X11, Arch Linux)

[notpeelz]

I played a couple hours of DRG earlier and didn't have the issue occur even once (still with the same config, ibus uninstalled, etc)

[LRitzdorf]

Same experience here, but just killing the IBus daemon was enough to fix it for me. Great to hear that we've found a solution — thanks for the tip! I'll also add a note to the Arch Wiki's page on IBus, so future users can find out about this more easily.

[kisak-valve]

The ibus issue should be reported to the ibus dev(s) if it hasn't been already.

[romulasry]

Okay opened one. ibus/ibus#2485

[notpeelz]

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2663

[ernstp]

This started happening for me on Ubuntu 23.04 (lunar) recently. Disabling ibus solved it. Lunar recently got ibus 1.5.28....

[Tuupertunut]

Note: There are two different bugs here. The original reported bug is different from the ibus bug that some people have recently mentioned:

• In the original bug, key presses are stuck temporarily, the time depends on how long the key has been pressed. Pressing the stuck key again does not help. A workaround is to disable "Repeat keys" from GNOME settings.
• In the ibus bug, key presses are stuck permanently. Pressing the stuck key again does help.

This thread is for the original bug. I can reproduce it in Arma 3 in low FPS scenarios, using Ubuntu 22.04, X11, GNOME 42.5 and Wine staging 7.17 (so not using Proton). Disabling repeat keys does indeed work around it.

[Mobiacikaka]

confirm the same problem running skyrim on Proton 8.

[Mobiacikaka]

solve it with command "xset r off". Just turn off the repeat key like the mate said in the front.

[Griffin30007]

I had same thing; in my case it was repeating keys (i prefer small delay / fast repeat setting). I just disabled it in settings -> accessibility -> repeat keys and everything seems to work ok now.

This is the solution.

[prosac]

For me #5294 (comment) fixed it. For sure that is no complete solution, since I do not want to disable and enable repeat-key manually when switching between gaming and coding, but for now I am satisfied.

[fansari]

I had same thing; in my case it was repeating keys (i prefer small delay / fast repeat setting). I just disabled it in settings -> accessibility -> repeat keys and everything seems to work ok now.

Great hint! I was replaying Lacuna and wondering why control over the character is that bad - it had worked in the past. Now I got stuck regulary and was unable to change the direction of the character. After disabling "repeat keys" in Gnome it worked as it did before. I don't know what has changed. I am playing Lacuna with Fedora 39 Silverblue with Steam as Flatpak and Proton 8.0.4.

I have also tested the solution with ibus. When the problems occurs I can do "ibus restart" and it works again.

The advantage of this solution is that "repeat keys" can stay enabled.

Also I have tested "ibus restart" directly after starting Steam. This also prevents the issue. When I run this command before I start Steam it has no effect and the problem occurs.

Here another solution to prevent this issue (currently the one I will use if it does not have other side effects).

I put this into my ~/.bashrc:

export IBUS_ENABLE_SYNC_MODE=2

After I did this I don't need the restart ibus after starting Steam.

My ibus version is ibus-1.5.29~rc2-6.fc39.x86_64.

ibus/ibus#2480

ibus/ibus#2599

[maximilionus]

It looks like the issue is in ibus processing mode. It can run in sync and async modes, depending on the distribution configuration, with issues starting to appear on synchronous mode used as default (which it is, if not modified).

I made a quick search in the ibus source code and turns out that IBUS_ENABLE_SYNC_MODE environmental variable can be used to switch between these processing modes. There can be 3 modes of processing, with the synchronous mode used by default:

• Value 0: Asynchronous mode.
• Value 1: Synchronous mode (used by default, if not modified by distro).
• Value 2: Hybrid asynchronous mode.

Setting the environmental variable to 2 or 0 completely fixed the input lag for me, as the @fansari also reported above. There are a lot of methods to do that, but I personally prefer the modular one, using the profile.d:

• File /etc/profile.d/90-ibus-lag-fix.sh

# Enable ibus hybrid asynchronous processing
export IBUS_ENABLE_SYNC_MODE=2

I am not completely aware of how the "hybrid" async mode (2) differs from the original async mode (0), but it looks like a more preferable solution.

It could also be the case that this is highly dependent on the user's GPU, because this seems to be a problem specific to NVIDIA. I'd like to hear if there are any AMD users here who have been affected by this issue too.

[Mershl]

related ibus issue: ibus/ibus#2618 (comment)

[PimpOfSune]

IBus 1.5.30 . Fresh install of Ubuntu 24.10 x64 Desktop.
Deep Rock Galactic is unplayable since the moment my FPS drops to around 30 (which happens ALOT on my lousy hardware) - key inputs become sticky.
I was able to play just fine for a YEAR. Problem appeared only recently.
I'm not running other as resource-intense games through Proton yet.

[pt300]

I also started having issue with stuck input that sometimes resolved itself sometimes not. Whether it happens didn't really correlate with anything, other than playing games through proton. Additionally, the games would freeze if I tab out.
The issues started after upgrade to Ubuntu 24.10, with ibus version 1.5.30. My current fix is just downgrading ibus to version from Ubuntu 24.04 by adding the noble ppa and then downgrading and locking the 1.5.29-rc2 version.