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.

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.

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

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

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.

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

Same issue: Fedora Rawhide.

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

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.

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.

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.

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.

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.

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

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.

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

Xwayland 23.0.99.901

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.

Sounds like a problem in ibus, no?

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 :sweat_smile: My issue doesn't seem to be related to low FPS either.

Mine get stuck until I alt+tab.

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.

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

Wayland, sway.

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

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)

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)

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.

Okay opened one. https://github.com/ibus/ibus/issues/2485

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

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

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.

confirm the same problem running skyrim on Proton 8.

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

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.

For me https://github.com/ValveSoftware/Proton/issues/5294#issuecomment-1236124959 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.

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.

https://github.com/ibus/ibus/issues/2480

https://github.com/ibus/ibus/issues/2599

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.

related ibus issue: https://github.com/ibus/ibus/issues/2618#issuecomment-1981921727

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.

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.

World of Warships (problem with shift)
IBus 1.5.31
6.12.1-4-MANJARO

Trick with IBUS_ENABLE_SYNC_MODE=2 didnt help me
Works only killall ibus-daemon

Guys, anyone who has this problem, do you have a connected NTFS disk?

World of Warships (problem with shift) IBus 1.5.31 6.12.1-4-MANJARO

Trick with IBUS_ENABLE_SYNC_MODE=2 didnt help me Works only killall ibus-daemon

Guys, anyone who has this problem, do you have a connected NTFS disk?

-> I can confirm this behavior (on Kubuntu 24.04, w/o any NTFS disk attached)
Shift needs to be pressed longer and German Keyboard Layout not working correctly ("Umlaut" in in-Game-Chat not working - only if CTRL key pressed [weird])

I noticed recently an IBus task symbol after an update -> "killall ibus-daemon" helped before starting the game

After a quick search how to disable it completely i found this:
https://hexqode.com/how-to-disable-unwanted-services-and-daemons-in-ubuntu-22-04/

• can't confirm it now, I will try it later

Same issue on all games I play 2026. Proton experiemntal. Using latest bazzite gnome.
Nvidia drivers.
4090 so this is happening even at high 140 fps.

Really hope this is addressed.

TBH this seems to be a GNOME issue rather than Proton. I've since switched to KDE and never had this problem again.

Can confirm a partial fix - had the same problem on Linux Mint 22.3 Zena (Gnome)

Following @amalkus 's comment

IBUS_ENABLE_SYNC_MODE set to 1 or 2 didn't work on its own.

running killall ibus-daemon and then with the launch options env IBUS_ENABLE_SYNC_MODE=1 gamemoderun %command% worked without issue for over a half an hour before I called it a night.

Feral's gamemode is likely not relevant and it is most likely IBUS getting in the way.

I can confirm that killing ibus-daemon fixes the problem. The env was not enough by itself. ibus 1.5.29-2 on ubuntu with cinnamon. All 3 affected games/demos were Unity engine. No issues with other titles.

Same here with killing ibus-daemon: https://github.com/ValveSoftware/Proton/issues/9568#issuecomment-4049763653

I'm not sure this is caused by low framerates unless a 3090Ti is struggling to get 60fps in basic Unity game demos in 2026. Maybe it is, but I'd be a little surprised. In any case, I found that the persistent keys stuck forever, not just based on a framerate.

I am sure it's not low framerate at least in my case. The unity games/demos it happened in were not pushing my gpu at all. I had stable high framerate

I've had this problem with Marvel Rivals, which runs with at least 160 FPS on my machine, so I don't think it is related to FPS. Again, all I can say is that the problem completely disappeared after switching to KDE, but of course it would be great to find a real solution for those wanting to stick with GNOME.