Keyboard input "sticking" on GNOME at low FPS

SilverStraw commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

romulasry commented 1 year ago

Same issue: Fedora Rawhide.

romulasry commented 1 year ago

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

notpeelz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

notpeelz commented 1 year ago

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 commented 1 year ago

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

Xwayland 23.0.99.901

notpeelz commented 1 year ago

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 commented 1 year ago

Sounds like a problem in ibus, no?

notpeelz commented 1 year ago

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.

romulasry commented 1 year ago

Mine get stuck until I alt+tab.

eternal-sorrow commented 1 year ago

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 commented 1 year ago

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

eternal-sorrow commented 1 year ago

Wayland, sway.

romulasry commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

romulasry commented 1 year ago

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

notpeelz commented 1 year ago

ernstp commented 1 year ago

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

Tuupertunut commented 1 year ago

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 commented 12 months ago

confirm the same problem running skyrim on Proton 8.

Mobiacikaka commented 12 months ago

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

Griffin30007 commented 11 months ago

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 commented 9 months ago

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.

fansari commented 9 months ago

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

maximilionus commented 2 months ago

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 commented 2 months ago

ValveSoftware / Proton

Keyboard input "sticking" on GNOME at low FPS #5294