https://universal-blue.discourse.group/t/input-lag-while-gaming/5289
Someone else had a similar problem and their fix may help.
Nice, that does seem to be the issue! By searching for that environment variable, I also found this: https://www.reddit.com/r/linux_gaming/comments/1eqrnjr/psa_recent_ibus_releases_introduce_noticeable/
It seems IBus is the cause of this lag. I have made the change as the post you linked suggested, and it seems to have fixed it! I found some people having issues with the value of 0 and so will try out for a while to see if the hybrid 2 value is stable.
I have Bazzite but for handhelds and I knew they did have some issues with input lag but couldn't remember the specifics. Glad I could help and that you found a solution that works.
I don't know what would cause a second or more of keyboard-specific delay.
Hmm.
I think the first step I'd try is running them in windowed mode with evtest running in a terminal alongside your game, so that you can see both at once. That can display a list of all keyboard events as they come in. If evtest is showing the events immediately as they come in, but Doom isn't responding quickly, then the kernel is reporting the events quickly, and it's Doom not processing them quickly. If evtest is delaying display, then there has to be something at the hardware or kernel level that's problematic.
That won't alone solve your problem, but it'll help narrow down what the cause is.
Thanks! evtest shows keyboard events happening immediately. The game seems to be the one slow to respond.
Hmm.
Both games you listed appear to run in Proton.
Dave the Diver is a Unity game, and Doom (2016) uses id Tech 6, so not a lot of common underlying technical infrastructure at the game level. I can't imagine that it's a common bug in both games.
That does kind of suggest something related to Proton, between Linux and the game, but I don't know of anything that could create a backlog at the Proton level. I mean, keyboard events aren't terribly heavyweight.
I haven't played Doom (2016), but it's a multiplayer game and some multiplayer games might have network latency for movement produce delay, but not for simply panning the camera
though I'd think that this would have more-sophisticated client-side prediction stuff; Quake II did. Dave the Diver is singleplayer, though, so if the mechanism is the same, shouldn't be a network issue.
I don't know, frankly. Kind of drawing a blank. Maybe try, in Steam's Compatibility settings for the game, a different version of Proton? Not that I can think of a specific mechanism that would cause this, but I can't think of much else that would be shared between the games, wouldn't affect the mouse, and would affect the keyboard, and that you could readily change.
EDIT: One other possibility
maybe try disabling Steam Input for the game and see if it affects the issue? Steam does do some processing. I can't think of any reason that it'd insert a lot of latency, but it'd be one of the few other things that would live between the kernel and the game.
EDIT2: Actually, no...I don't think that Steam Input touches keyboard input, based on a quick search. Just controller stuff.
EDIT3: Oh, wait. Gamescope. I've never intentionally used it, but it's some kind of mini-compositor that Steam uses.
And it looks like it touches keyboard input:
https://github.com/ValveSoftware/gamescope/issues/1460
I don't know much about Bazzite, but I understand that it's a Fedora distro aimed at being an alternative to SteamOS, so I could believe that they use gamescope.
kagis
https://universal-blue.discourse.group/t/gamescope-gamemode-for-desktop/3893
With bazzite there is no need to install gamescope as it is baked onto the image
It looks, from that page, like there's some global toggle for gamescope, and people normally enable it on a per-game basis by adding it to the game's launch properties in Steam, but I can't give a lot of advice there; haven't used it myself.
I might try disabling gamescope, if you're using it, and see if the issue vanishes.
And...hmm...on that note, maybe also try disabling the Steam Overlay. That touches keyboard input, and also touches the video display.
https://help.steampowered.com/en/faqs/view/3978-072C-18DF-FBF9
Open the Steam client and navigate to the Steam > Settings > In-game tab. Toggle on Enable the Steam Overlay while in-game.
Just to see if that makes the issue go away.
So this is a bit of a dumb solution, but I went to the accessibility settings in the OS and dropped the repeat frequency a bit. Now it seems to work fine!
It did seem like the events were triggering faster than the games could process them, so dropping the repeat speed a little stopped the events queueing up.
That’s getting old school. I had to do the same thing to get Shovel Knight to accept input properly about 10 years ago.
I sent a message to the dev about it, but there wasn’t a Linux port yet so they were stumped. I changed the repeat rate of the key input in kde and there it went like magic.
Another comment has this down to a bug in IBus, which is for supporting typing non-latin characters.
https://lemmy.nz/post/23401044/15684126
So I get a proper solution, mostly (I think a proper proper solution would be having the bug fixed)
Okay, sounds good! Glad to hear it.
Are you using the handheld/deck image? If so, see if you can replicate the issue in desktop mode as it might be a game mode specific issue. I'd also test a different keyboard and gamepad, if you have easy access to those.
No, it's the desktop edition. It's a laptop, but I have a wireless keyboard that I plugged in and tried. It didn't help, same thing.
One thing I noticed is that it appears to happen only when holding down a key. So for example, if I tap left then tap right, the character reacts instantly. But if I hold down left and the character is going left, then I switch to pressing right instead, it can take over a second to react. Like it's not able to process the key presses as fast as they are being generated.
We need more specs. Input lag is almost always due to resource constraints, and in gaming because the kernel is busy trying to to keep itself alive in some sense (meaning the scheduler is going crazy). My guess is this is a memory issue, so get your memory util while the games are running with free -m and post that, and also get dmesg output when the lag hits.
It should give some extra info. I'm guessing you've got a memory constrained system with regard to gaming, and insufficient swap on Bazzite.
So this is a bit of a dumb solution, but I went to the accessibility settings in the OS and dropped the repeat frequency a bit. Now it seems to work fine!
It did seem like the events were triggering faster than the games could process them, so dropping the repeat speed a little stopped the events queueing up.
👍
If it works, it works.
At the same time as installing Bazzite, I also upgraded to 64GB RAM.
Here's the output of free -m when the game is being problematic.
$ free -m
total used free shared buff/cache available
Mem: 64076 14703 43303 3643 14036 49372
Swap: 4095 0 4095
Here's a pastebin of the dmesg output: https://pastebin.com/N6h3HP7D
I am sure you're right about it being resource contrained. It seems to get worse over time, and the GPU reports 100% all the time while the game is running. Just trying to work out if there is something I can change to make it happier.
The issue is you say it didn't have this issue when it was running a different distro, so we know there is an acceptable state somehow. What the delta between that install and this current one is the question.
That being said, there isn't anything obvious in the dmesg output. You ran that command WHILE the problem was happening, right?
That being said, there isn’t anything obvious in the dmesg output. You ran that command WHILE the problem was happening, right?
Yes, as close as I could. I had the game open and while using it the keyboard actions were delayed. Then I switched to the terminal to run the commands. So I guess not while I was pressing keys in the game, but I did it at a time when the keyboard controls were lagging.
Edit: One thing I noticed is that it appears to happen only when holding down a key. So for example, if I tap left then tap right, the character reacts instantly. But if I hold down left and the character is going left, then I switch to pressing right instead, it can take over a second to react. Like it’s not able to process the key presses as fast as they are being generated.
So this is a bit of a dumb solution, but I went to the accessibility settings in the OS and dropped the repeat frequency a bit. Now it seems to work fine!
It did seem like the events were triggering faster than the games could process them, so dropping the repeat speed a little stopped the events queueing up.
Yeah, you're not running into paging issues. That's plenty of memory available.
I have (sort of) solved the issue. When holding a key down, the events seem to be firing faster than the games can keep up with. The longer a key is held down the more it queues up. So if I hold left for a while, then suddenly switch to right, it seems to have a backlog of left events to get through before it processes the right event.
I went into the system settings and changed the keyboard repeat speed to be a bit lower. Now it seems to send events at a speed the games can keep up with, even if I'm holding down a key.
I'm not sure if this counts as a real solution but it seems to solve the issue for me, and I doubt I'll notice the slightly slower repeat frequency (I think games are only listening for the up/down events so the repeat frequency probably doesn't affect them).
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
WWW:
Discord:
IRC:
Matrix:
Telegram: