lag spikes after 25-40 minutes of playing on linux
Can confirm the findings of that thread on KDE Tumbleweed Wayland.
It started happening around the time "record your game" rolled out for me.
Valve should fix all the preload errors that spam the console when using it and playing games
Pulling this from a reddit topic I saw where the user also had the issue, may be relevant:
"When I run 'top' in the terminal I see the game running 'engMain', when I have it focused, the %CPU will show somewhere between 300 - 400 when not moving my mouse - the game runs fine. When I touch my mouse the %CPU value plummets to about half of whatever was initially shown and the game stutters. This does not happen when the game is initially started"
I'm the one who started this recently in the other repo issues and I can confirm that it is still happening. You can get rid of this by using LD_PRELOAD="", but you can still use LD_PRELOAD to preload your own libraries.
Can confirm the findings of that thread on KDE Tumbleweed Wayland.
It started happening around the time "record your game" rolled out for me.
Exactly.
Also happens to me on gnome 47, Wayland, fedora 41, Nvidia 560 and 565, started happening when the game recording update came out.
Additionally I'm not sure if it's part of the same problem but with the overlay enabled doing nothing (no game recording enabled, no windows, no chat, nothing) the overlay vram usage balloons to almost 2gb reported by nvidia-smi.
@kisak-valve I just want to add that this also happens when the overlay is turned off through the Steam UI.
(with also both game recording and steam input disabled as well, from the UI of course)
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2466438353
Having the same problem, started after the Steam Game Recording update as well, enabling the overlay fixed the problem.
I've had this issue for years https://github.com/ValveSoftware/csgo-osx-linux/issues/2901 but I only play 1-2 games, so after CS:GO moved to CS2, the issue went away.
But for years, CS:GO using DXVK native required LD_PRELOAD=""
gameoverlayrenderer.so most likely culprit
gameoverlayrenderer.so most likely culprit
It definitely is.
But many of us have the steam overlay and recording feature turned off in the options. So why would it even load that?
But many of us have the steam overlay and recording feature turned off in the options. So why would it even load that?
That's probably part of the bug. /environ shows that the library still loads even though those things are turned off. Hence why LD_PRELOAD="" fixes the issue (prevents said library from loading).
While it does seem like people have helped corner the source of the issue, I figured a little more information couldn't hurt.
Note that using LD_PRELOAD as SheMelody suggests appears to have fixed my issues, will need to test further to confirm but initial tests has been very promising. A huge thank you to them as when I look further at this issue it's clear they put in a lot of legwork on trying to help pinpoint this issue.
After the steam update about a week ago, the one that apparently added in additional recording features as well as updated to runtime environments scout, soldier and sniper, both of my linux systems would have issues playing games through proton. I'd notice the odd tiny bit of jitter while playing, but after 20-50 minutes (depending on game and game settings) I'd start getting horrible framerate drops whenever I...
- moved the mouse
- gave input on the keyboard
The stuttering would last for about a second after the input stopped, and if the input was just a single key press that was held for a few seconds it would stop. As I had a controller connected I switched to that and the game I was playing (subnautica) ran perfectly smooth, went back to mouse and keyboard? Stuttering. This stuttering also appeared to be framerate only, as on the main menu of one of the games (Again, Subnautica) the mouse cursor would move smoothly, but the background animations would stutter like mad while I was moving the cursor once I had hit this 'time to stutter' threshold.
So whatever issue is involved with this overlay issue is also tied with mouse and keyboard input. At least on my end after some testing. What I did not do is continue using the controller for another 50 minutes or so to see if there's some sort of 'input buffer' that fills up with a specific kind of input that would cause the controller input to start lagging.
This was also exclusive to steam, as I have games that run natively on linux or I use regular WINE for that do not suffer this stuttering issue.
I'll also give additional system information on both of my systems below, the only thing that unifies the two systems is that they are linux, are AMD CPU and graphics and the three games I tested had some sort of internet traffic, though both machines run on completely different internet connections (wired/wi-fi) and ISP's.
Desktop (Tested with Subnautica with Archipelago multi-world randomizer):
- Custom build
- Arch Linux : KDE Plasma 6.2.3 , Wayland
- CPU: AMD Ryzen 9 7900X 12-Core
- Graphics: AMD Radeon RX 7900 XT
Laptop (Tested with Helldivers 2 and Mechwarrior Online):
- Framework 16 Laptop
- Linux Mint 22 Cinnamon (Cinnamon 6.2.9) , x11
- CPU: AMD Ryzen 9 7940HS
- GPU: AMD Radeon RX 7700S
Steam overlay has been entirely disabled through the Steam UI on both PC's as well.
Yes, LD_PRELOAD="" fixes it for me as well, but do I need to put it in the launch options for every game or can I set it globally?
Yes, LD_PRELOAD="" fixes it for me as well, but do I need to put it in the launch options for every game or can I set it globally?
Do not set it globally, no.
I've been having the same symptoms using conty_lite.sh w/ Slackware current from the 8th Nov or so: Subnautica becomes unplayable slideshow after 1/2 hour to an hour (playing with kb/mouse).
After the LD_PRELOAD workaround this seems to have gone away. Thanks for that!
I still see "ERROR: ld.so: object '/home/pete/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored." with the workaround in place and overlay disabled for the game and then disabled globally.
Wonder if it's some byproduct of setenv changes ?
Disabling steam game recording on a per-game basis through its settings UI seems to solve this issue for me without losing other things. (Game tested: Warframe)
If you're using gamemode you can just use this hack to temporarily hide gameoverlayrenderer.so from the game without messing with other libs:
~/.config/gamemode.ini
[custom]
start=mv ~/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so ~/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so.bak; mv ~/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so ~/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so.bak
end=mv ~/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so.bak ~/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so; mv ~/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so.bak ~/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so
UPD. No, it isn't the best approach because gamemode doesn't wait for script to exit so it's possible it'll launch the game before the lib is hidden.
Had similar issue with The Witcher 3. After 30-50 min of smooth playing, the game stutters significantly with constant FPS drops.
Launching the game with LD_PRELOAD="" seems to have fixed the issue.
TBH: if all you want to add to the bug is "oh yeah i had that issue too and the solution helped me" please just click the thumbsup in the initial post in this thread. those comments do not add any more useful information to the issue.
Thank you in advance.
I want to add that doing LD_PRELOAD="" breaks the steam ingame overlay (obviously) but also doesn't completely solve the issue. Anytime steam pushes a notification, such as a friend going online, the system hangs will still happen. As well as having the full steam interface as the primary application will cause major slowdowns with a game running. Minimizing the steam window (or having it in the background) is fine.
I got this problem on Fedora KDE (Wayland NVIDIA). I notice that in the console when the stuttering happens, I get this message: [InputSystem] Processing SDL events took 50.1ms, spammed in the console.
Edit: This was for Counter Strike 2. Forgot to mention the game.
We can probably try to add VK_LAYER_VALVE_steam_overlay_64 (or the 32-bit version depending on the game) to the VK_LOADER_LAYERS_ENABLE variable.
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_VALVE_steam_overlay_64 %COMMAND%
Haven't tried this, but it would be interesting if this doesn't cause the issue. Note: untested, and will only work with Vulkan / DXVK / VKD3D, and not with OpenGL / WineD3D.
I just want to add in, when I was having the cursor lag after 40 mins in game couple weeks ago it was present in both Steam and Lutris. So may want to test your current version of proton inside Lutris and see if it happens as well to narrow down the issue.
I had a similar issue with Dead by daylight where it starts lagging around after 30-40 minutes after I start playing. Adding LD_PRELOAD="" didn't do anything for me. However, I noticed that when I enabled the steam overlay(with steam recording still disabled) the lag no longer happened.
Did you add LD_PRELOAD="" or LD_PRELOAD="" %COMMAND%? You may need the %COMMAND% part for it to actually work.
Interestingly enough when I add LD_PRELOAD="" %COMMAND% Dead by Daylight will crash for me. I'm fine with just having the overlay enabled.
After looking at some older issues mentioned here (#2901) seems like this is an old issue and apparently the only known fixes are enabling overlay or adding the LD_PRELOAD flag.
Hopefully nobody with this issue needs to have the overlay disabled along with having the LD_PRELOAD flag solution not work for them...
Happens in unity games as well, by the way. Slipways and Against the Storm are both affected.
Interesting thing: During the lagspike frames, the game will not pick up any mouse or keyboard input; meaning, if you use short taps or clicks they can get lost. That makes trying to play anything reasonably quickly a big problem.
For me it seems to only lag with input (after ~30mins), so FPS is fine until I press/hold a key or move my mouse.
So far, this happened for me with every game with the exception of Slay the Spire, which is an OpenGL game.
Happens as well with Path of Exile 2 on its Vulkan renderer.
It doesn't happen for me in Path of Exile 2 using the LD_PRELOAD=""
%COMMAND% launch options.
On Tue, Dec 10, 2024 at 2:24 AM netborg-afps @.***>
wrote:
So far, this happened for me with every game with the exception of Slay
the Spire, which in an OpenGL game.
Happens as well with Path of Exile 2 on its Vulkan renderer.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2530643023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZK72ANT64HICKN2ENKUFD2E2JK3AVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZQGY2DGMBSGM
.
You are receiving this because you commented.Message ID:
@.***>
Yes, I just wanted to note that no workaround is needed for Slay the Spire - the only game I encountered so far which isn't affected by this bug.
I had a similar issue with Dead by daylight where it starts lagging around after 30-40 minutes after I start playing. Adding
LD_PRELOAD=""didn't do anything for me. However, I noticed that when I enabled the steam overlay(with steam recording still disabled) the lag no longer happened.
- Initially I had steam overlay disabled for The Witcher 3 and started seeing this issue.
- The
LD_PRELOAD=""workaround fixed the issue for me on The Witcher 3. - I also tried enabling the steam overlay and disabling steam recording. This also fixes the issue for me.
- When I do try to record something, the fps drops drastically in game (even after the recording has stopped).
with LD_PRELOAD="" the controller doesn't work
OS: Fedora 41Silverblue
Controller: PS5 Dualsense (I tried emulating it as Xbox 360 with xboxdrv and the same)
Steam (flatpak):
Steam Beta Branch: Stable Client
Steam Version: 1733265492
Steam Client Build Date: Mon, Dec 2 18:26 UTC -04:00
Steam Web Build Date: Mon, Dec 2 18:20 UTC -04:00
Steam API Version: SteamClient021
-------------------------------------------------------------
Command: cat /etc/os-release
NAME="Freedesktop SDK"
VERSION="24.08 (Flatpak runtime)"
VERSION_ID=24.08
ID=org.freedesktop.platform
PRETTY_NAME="Freedesktop SDK 24.08 (Flatpak runtime)"
BUG_REPORT_URL=https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues
-------------------------------------------------------------
Command: lspci -tv
-[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex
+-00.2 Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU
+-01.0 Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
+-01.1-[01]--+-00.0 NVIDIA Corporation TU106M [GeForce RTX 2060 Mobile]
| +-00.1 NVIDIA Corporation TU106 High Definition Audio Controller
| +-00.2 NVIDIA Corporation TU106 USB 3.1 Host Controller
| \-00.3 NVIDIA Corporation TU106 USB Type-C UCSI Controller
+-01.2-[02]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
+-02.0 Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
+-02.1-[03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
+-02.2-[04]----00.0 Intel Corporation Wi-Fi 6 AX200
+-08.0 Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
+-08.1-[05]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Renoir [Radeon RX Vega 6 (Ryzen 4000/5000 Mobile Series)]
| +-00.2 Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
| +-00.3 Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1
| +-00.4 Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1
| +-00.5 Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor
| \-00.6 Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller
+-08.2-[06]--+-00.0 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
| \-00.1 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
+-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
+-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
+-18.0 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 0
+-18.1 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 1
+-18.2 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 2
+-18.3 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 3
+-18.4 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 4
+-18.5 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 5
+-18.6 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 6
\-18.7 Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 7
-------------------------------------------------------------
Command: lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 002: Dev 006, If 0, Class=[unknown], Driver=snd-usb-audio, 480M
|__ Port 002: Dev 006, If 1, Class=[unknown], Driver=snd-usb-audio, 480M
|__ Port 002: Dev 006, If 2, Class=[unknown], Driver=snd-usb-audio, 480M
|__ Port 002: Dev 006, If 3, Class=[unknown], Driver=usbhid, 480M
|__ Port 003: Dev 003, If 0, Class=[unknown], Driver=uvcvideo, 480M
|__ Port 003: Dev 003, If 1, Class=[unknown], Driver=uvcvideo, 480M
|__ Port 004: Dev 004, If 0, Class=[unknown], Driver=usbhid, 12M
|__ Port 004: Dev 004, If 1, Class=[unknown], Driver=usbhid, 12M
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/2p, 480M
|__ Port 001: Dev 004, If 0, Class=[unknown], Driver=usbhid, 12M
|__ Port 001: Dev 004, If 1, Class=[unknown], Driver=usbhid, 12M
|__ Port 001: Dev 004, If 2, Class=[unknown], Driver=usbhid, 12M
|__ Port 003: Dev 003, If 0, Class=[unknown], Driver=btusb, 12M
|__ Port 003: Dev 003, If 1, Class=[unknown], Driver=btusb, 12M
|__ Port 004: Dev 005, If 0, Class=[unknown], Driver=usbhid, 12M
/: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/2p, 5000M
For those having the mouse studder after 40 mins, have you tested to play the game in Lutris? The reason I mention this because couple weeks ago, when the issue began to happen I was able to reproduce the studder in Lutris as well. In Lutris I pointed to the game .exe, and used different Wine versions for testing. The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
Sounds like a regression if latest DXVK-git suffers from mouse stutters
Have you tried to git bisect?
For those having the mouse studder after 40 mins, have you tested to play the game in Lutris? The reason I mention this because couple weeks ago, when the issue began to happen I was able to reproduce the studder in Lutris as well. In Lutris I pointed to the game .exe, and used different Wine versions for testing. The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
I don't think that's the case as I needed to put the workaround in place even though I was running my custom dxvk mod based on 2.4. The bug got introduced by a Steam update, not by some dxvk version.
For those having the mouse studder after 40 mins, have you tested to play the game in Lutris? The reason I mention this because couple weeks ago, when the issue began to happen I was able to reproduce the studder in Lutris as well. In Lutris I pointed to the game .exe, and used different Wine versions for testing. The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
I don't think these are the same stutter bugs. After I did the work around in FarCry5 the clockwork 27 minute stutter disappeared. I did experience a different stutter after an extended play, but the frametimes and frametime graph were totally different and took a lot longer to trigger.
The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
Sounds like a regression if latest DXVK-git suffers from mouse stutters
Have you tried to git bisect?
I didn't know of the feature at the time sorry. Actually slight correction, I can't say it was a git version anymore because I am not sure what Lutris had for settings when I reproduced the lag time bomb. More than that I can't tell you more because the TKG-Proton versions I had I deleted, but Lutris I may have the Wine versions so I will do some testing to see if I can produce the time lag bomb as I did. Sorry for the confusion.
I've had issues Satisfactory, see report at the Proton repo: [Proton #8313](https://github.com/ValveSoftware/Proton/issues/8313). Thought it was a polling rate issue of the mouse at first mentioned on the respective arch wiki page.
Tested Satisfactory pol rate at 500 Hz, the issue came back after >60 minutes instead of >30 minutes consistently.
Tested Path of Exile 2 pol rate at 500 Hz, the issue arose after >30 minutes consistently.
What actually did work was setting the launch options for both games LD_PRELOAD=" ". Both games ran consistent as can be expected for my system.
Tested Satisfactory pol rate 1000 Hz, issue not observed after a continuous >120 minute session.
Tested Path of Exile 2 pol rate 1000 Hz, issue not observed after a continuous >240 minute session. (Woops, jup that long.)
What I interpret is that the old Wine bug is not what causes it, or it's very inconsistent (hence not solved after 5 years.)
Thank you for providing a workaround SheMelody :heart: :+1:
I'm having the problem in overwatch 2 through steam even with LD_PRELOAD="" %COMMAND% in GE-Proton-9-21 and a few other 9.x i tried.
I'm currently testing geproton-8-26 and it hasn't happened yet. Found an old post saying the problem was in the 9 series and wanted to give it a shot. Edit: To give more info though, a few days ago I did install dxvk 2.5.1 and I don't remember now if it started then but it might have. I also installed 565 nvidia drivers a week ago. I wasn't play every day so I don't know when the problem started. Interesting that someone else mentioned dxvk versions though. Up until now though 2 hours later the problem doesn't occur with geproton 8.26 and 8.32. Still would like to run the latest versions and pinpoint where the problem is.
:final edit:
With steam overlay turned on in steam settings and LD_PRELOAD="" %command% it now works with 9.x geproton. I don't know why turning on steam overlay would do anything considering ld_preload is supposed to disable it but I tried it anyway. I also changed %command% to lowercase though and that's probably what fixed it. LD_PRELOAD= by itself also wasn't enough.
For those having the mouse studder after 40 mins, have you tested to play the game in Lutris? The reason I mention this because couple weeks ago, when the issue began to happen I was able to reproduce the studder in Lutris as well. In Lutris I pointed to the game .exe, and used different Wine versions for testing. The solution at the time was to not use the latest git compile of DXVK but instead use the release version which fixed the 40 min lag.
I do, I just found out that it's a different problem that coincidentally began to happen at around the same time.
When such stutters happen, I can see [drm] Fence fallback timer expired on (gfx|comp) blah blah in journalctl, and I find out that it only happens on KDE Wayland, not at all on Hyprland and Sway, and totally independent of whether Steam is running in the background or not. Updating / tweaking various BIOS settings and kernel parameters didn't solve the problem on KDE.
Since KDE is run on iGPU (7800X3D) on my system (but games are on 7900XTX), the timer expired problem might have something to do with how KDE handles iGPU rendering or drm.
Maybe give Hyprland and Sway a try.
I've experienced this issue in Dota 2. It starts randomly after some time in game. LD_PRELOAD="" %command% in Steam launch options fixed it.
Obligatory useless comment: the quotes are unnecessary, simply do LD_PRELOAD= %command% instead.
Likely doesn't affect Steam Deck hence likely all this wait is for nothing, get used to using Steam games like that for a year.
Confirming LD_PRELOAD="" %command% is working for me in Rust. (XUbuntu 22.04, Proton Experimental, RTX 3080, AMD 5950X)
- Fixes Remote play not working / not starting stream
- Fixes lag spikes after a while playing game
Also having this issue here.
That bug has been driving me crazy for some time now...
Thankfully LD_PRELOAD=" " %command% solves the issue
That Game Recording update is definitely broken
TBH: if all you want to add to the bug is "oh yeah i had that issue too and the solution helped me" please just click the thumbsup in the initial post in this thread. those comments do not add any more useful information to the issue.
Thank you in advance.
Seems I Found another workaround:
- Enabling Steam Overlay
- Disabling GPU accelerated rendering in web views
Could be related to #11479
Played Cyberpunk 2077 for like 2 hours without issue
Can anyone confirm if it's working on their end as well?
Can this issue be locked yet remain open @kisak-valve, with a summary of what happens, what is the workaround, noting Deck just works so it is not a priority.
So people wouldn't be able to add +1 comments and grasp the situation.
Instead of commenting "I have this issue in X Y Z game" please just thumbs up the first post.
If you are experiencing lag in games, it seemed to have started happening when valve released the screen recording update. From personal testing, it seems that as long as steam is being rendered at all this bug can happen including when a game is not open. Minimizing steam with no game running has solved the idle lag for me. Steam notifications being displayed may still cause issues. The steam overlay may cause issue even when you can't see it. Turning off game recording in steam will not fix this.
Users have reported mouse movements resulting in 50 ms processing the SDL library each frame I suspected this to be the root of the issue, but am not certain. As SheMelody pointed out below, people with newer SDL libraries are also having the issue.
-
Some users have said that the lag went away for them by enabling the steam overlay. However, a bunch of other users have tried enabling and disabling it noticing no difference.
-
You may want to try adding
LD_PRELOAD=" " %command%to your game launch options. This will likely break overlays, including steam's. However it will definitely get rid of the lag while in game. If you have other launch arguments for the game, you will want to add them AFTER the %command%, if you have other environment variables put them before the %command%, and if you wrap the game in another program put after the environment variables but before %command%. You can also add your own libraries between the quotation marks should any tool you need require libraries to be loaded. You do not need to worry about steam's input handling to break, controller binds will still work.
For example: TF2 with border-less window and mangohud would look likeLD_PRELOAD="" mangohud %command% -noborder -windowed -
Personally, I found disabling steam hardware acceleration in web views solved the issue with steam notifications and steam being open causing incredibly lag.
- Shrinking or hiding Steam doesn't solve the problem, and trust me, I have tested a lot.
- Hardware Acceleration on Steam has always been disabled for me to begin with
- SDL on its own is fine. Older versions of SDL have buggy mouse movements in Windows but not in Linux. No idea if this is what you were referring to.
- It's definitely the game recording update causing all of this.
- You can still
LD_PRELOADyour own things anyway and the lag won't happen, as long as the overlayrender one is not injected. Steam Input will also work even withLD_PRELOAD=""
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2560237661
- Edited my post to be more clear that I meant if you were having performance issues with steam, with no game running.
- Have you tried disabling all of them? Maybe try enabling and disabling it again in case there is some weird desync issue?
- I'm on linux personally and am having the issue with mouse movements causing lag.
- Yes. It I agree the issue happened as soon as that update went live. However, considering disabling screen recording does not fix it, I do not want to imply the problem is screen recording itself.
- I will include that as well.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2560245698
It's also being discussed here because this seems to happen especially with DXVK/VKD3D games rather than native (API) games.
I'm just asking, but is this planned to be fixed within the next Steam client release or so? Because I really find the Steam overlay useful for my own reasons.
i also got it fixed using PROTON_USE_WINED3D=1. So most probably issue happens with overlay only for vulkan mapping. In current moment 2 way to workaround : PROTON_USE_WINED3D=1 and LD_PRELOAD
For me the issue showed up only in a game (Helldivers 2) in which I tried to use that new recording feature. People have reported seeing the issue in path of exile 2 but I have zero issues with it, I also didn't try to record that game using this feature.
Could be totally coincidental but I didn't see this being mentioned as a potential cause.
Helldivers 2
AMDGPU might experience poor GPU performance in Helldivers 2 due to MESA overriding user's power profile
Reference:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28260
Easiest way is to disable this with a environment variable:
# /etc/environment
radv_force_pstate_peak_gfx11_dgpu=false
https://gitlab.freedesktop.org/mesa/mesa/-/issues/11046#note_2381270
Alternatively, remove the offending line in /usr/share/drirc.d/00-radv-defaults.conf
<application name="Helldivers 2" executable="helldivers2.exe"> <option name="radv_force_pstate_peak_gfx11_dgpu" value="true" />
Furthermore with AMDGPU, you'd get better results with power_dpm_force_performance_level = manual and pp_power_profile_mode = 1 (3D_FULL_SCREEN) power profiles than the default, see: https://gitlab.freedesktop.org/drm/amd/-/issues/1500#note_1448388
Good luck
Having a similar issue, however only with Ship Graveyard 2, Bodycam and Cyberpunk 2077 after playing for an hour. Other games such as HOI4 and GR Breakpoint run absolutely fine.
I've tried clean installs of different Pop OS Nvidia drivers, changing GPUs (Used a 2070 S before) before manually installing NVIDIA-Linux-x86_64-550.142 from Nvidia's website (Recommended driver for my 3060).
It's not a hardware issue, nor is it overheating or memory leak. At a loss right now, but will try u/spezdrinkspiss advice from this thread .
OS: Pop!_OS 22.04 LTS x86_64
Host: MS-7C56 1.0
Kernel: 6.9.3-76060903-generic
Shell: bash 5.1.16
Resolution: 3440x1440
DE: GNOME 42.9
Terminal: gnome-terminal
CPU: AMD Ryzen 7 3800X (16) @ 3.900GHz
GPU: NVIDIA GeForce RTX 3060 Lite Hash Rate
Memory: 5841MiB / 32021MiB
Just wanted to add a comment here and state that I turned off the steam overlay for Space Marine 2 when it came out and never turned it back on. Was experiencing this same lag/stuttering issue when playing Starcraft 2 and Heroes of the Storm around the 30 minute mark and never really connected the dots until seeing this thread. I just turned the overlay back on and played SC2 for over an hour without any issues at all.
i am having this issue since oct 24, in any game and tried so many thinks, including several OS reinstalls and GPU switchs
Thanks for all the information
Reenabling the Steam Ingame Overlay solved the issue for me, although i dont use nor like it, hopefully this is getting patched.
I was having this issue with 7 days to die with proton (native version unplayable in general), after ~45-60 minutes of gameplay the stutter would kick in.
What I figured out was that the stuttering was down to input of any kind, if I moved my mouse it would stutter every few frames, if I walk forwards, I stutter once when I press W, and then the game starts running fine while I hold W, if I tap any other key on my keyboard while holding W & walking I can produce a single stutter with each keypress.
I'm not 100% sure this issue here is the same one but I did manage to go about ~90-100 mins last night with LD_PRELOAD="" %command% and not run into the issue before I had to log off for the day, I had tried everything else prior with no luck (every possible game setting/renderer, proton version, etc). Steam overlay on or off made no difference to this issue occurring for me, it would happen regardless.
I'll hopefully play for longer today or tomorrow and verify if this does indeed fix my issue for sure or not.
Edit; Yeah, LD_PRELOAD="" %command% resolves the issue for me in 7 days to die.
I went ahead and thanks to discoveries made by @alexzk1 on this DXVK issue: https://github.com/doitsujin/dxvk/issues/4436
I made some tests while playing a 32bits game (Ys Memories of Celceta):
The issue seems to be the 64bits gameoverlayrenderer.so interfering with a 32bits game or 32bits one with a 64bits game (to be confirmed) and seems to only affects 32bits games.
That means:
- 32bits gameoverlayrenderer.so inactive & 64bits gameoverlayrenderer.so active => No Steam Overlay & Stuttering after 40mins
- 32bits gameoverlayrenderer.so inactive & 64bits gameoverlayrenderer.so inactive => No Steam Overlay & No issue
- 32bits gameoverlayrenderer.so active & 64bits gameoverlayrenderer.so inactive => Steam Overlay & No issue
The method i used is to just chown root:root & chmod -rw 64bits gameoverlayrenderer.so file.
That way, you still have Steam overlay active and no need to use LD_PRELOAD.
Since this is still a hassle, alternatively you could use LD_PRELOAD to load the appropriate steam overlay with your game depending of its architecture need.
With something like this (tested successfully, only for 32bits games)
LD_PRELOAD="/home/USER/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so" %command%
It effectively prevents the 64bits version of the overlay to be loaded using ubuntu12_32 libs but in case you want the 64bits version, the 32bits libs still gets loaded by the steam client itself as it remains active even after closing the game.
Maybe this still works for 64bits games, but that needs to be tested...
64bits games seems to be unaffected by this, at least in my testing (Horizon Forbidden West, Forza Horizon 4 with 1h+ of playtime without any issues)
Edit struggle ~ doesn't work as home in LD_PRELOAD path, good to know...
Enabling Steam UI help me too. Fedora 41/Xfce with steam 1.0.0.82. Issue was appearing constantly after >30minutes of Dota 2 gameplay.
I guess, when this get fixed, developers should explicit ask to disable workarounds and try the fix. Like pop-up 1 time.
Because we will not see any possible fixes :/
I have also been having this issue when playing the Kingdom Hearts 1.5+2.5 collection, since at least late December.
LD_PRELOAD="" does fix the issue for me, but the solution provided by @Slashic has also proven to work. For the Kingdom Hearts collection, I need to point LD_PRELOAD to the 64-bit overlay, meaning I set it to LD_PRELOAD="/home/USER/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so". For this, I am extremely grateful to Slashic for sharing their findings.
The Kingdom Hearts collection is a bit of a weird one, because it's split between multiple .exe's for the launcher, the different games, and some cutscene viewers, and some of those .exe's are 32-bit while most are 64-bit.
EDIT: It seems I spoke too soon... I'm still getting the bad, rhythmic stuttering after playing for long enough when only loading the 64-bit overlay. A curious issue since it's been mentioned that for some, it doesn't happen with 64-bit games.
Seems like a easy fix for Mr Gaben!
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2606088405
That's interesting, that would mean it's not a 32bits/64bits game issue but more the 64bits overlay causing an issue in some games.
It could be interesting to start listing games that are affected and those that aren't in order to find what's causing the issue (game engine, DX9/11/12...)
Feel like it would be easier to just list what works. Looking at the linked topics here and what i saw on reddit, it affects basically every game and every distro.
The only game not affected in my library is Stalcraft which runs on native openGL.
Also kind of strange how we got like 2-3 mayor steam updates without this issue being addressed.
Feel like it would be easier to just list what works. Looking at the linked topics here and what i saw on reddit, it affects basically every game and every distro.
Potentially every distro aside Steam OS, but every game, i doubt that's the case, i tested 2 games that seems to works perfectly fine without any alteration to LD_PRELOAD.
Also if that problem was so widespread the whole Steam Client Linux forum would've been flooded by now.
Feel like it would be easier to just list what works. Looking at the linked topics here and what i saw on reddit, it affects basically every game and every distro.
Potentially every distro aside Steam OS, but every game, i doubt that's the case, i tested 2 games that seems to works perfectly fine without any alteration to LD_PRELOAD. Also if that problem was so widespread the whole Steam Client Linux forum would've been flooded by now.
It took me months to figure out the cause of the issue and even consider it was a Steam issue. I first thought it was a problem with a Dark Souls 3 mod. Then it happened in Talos Principle, but since the game ran awfully anyway, I didn't connect the dots. Then it happend in Ratshaker and I realized it might be a systematic issue, but googling around didn't yield any useful results. I think it happened in Monster Hunter Rise too. Only after it happened in Armored Core VI and I realized it only happened when I moved my mouse, did I eventually stumble across this GitHub issue after multiple search sessions. And I only did because I played Armored Core with KBM instead of controller, since using a controller and not touching the mouse did prevent the lag in my case in that instance.
That is to say that people might just be lucky and while their game and system might be succeptible to this issue, they might not be affected by it because of a combination of factors.
I am on Nobara Linux 41, and the listed games here are affected on my end. The only games I played since this started happening I do not remember having issues were 2D games like Balatro or Ballionaire.
The more data we have, the more we and steam devs will be able to reproduce and pinpoint the true root cause.
Be it: Tests cases with driver, game and distro for instance.
I'm going to do tests in more games when I have an opportunity.
My distro is CachyOS and my GPU is an RTX 4070 Super.
ArchLinux, RTX-3050,
Skyrim SE (frozen at ver 640) heavy modded - lags / crashes.
Elite Dangerous - low fps (but this is legal state for it). With fix works perfect except carrier docking.
TESO - without fix had to reload game each 20-30 minutes - mouse was stuttering, for example, it was not possible to move mouse to next pin in "unlock" mini-game. Image itself was causing headache.
Steam itself - everything is OFF (including GPU animations) which can be off. Also I tried to kill steam's webhelper, it didn't help.
"Fix" just fixes all games at once.
I have only mouse & external keyboard connected to the laptop. No more devices.
$ steam-native is my dailydriver and haven't encountered this issue yet.
Tested using 2 computers with Steam Overlay enabled on Arch Linux
$ steam-nativeis my dailydriver and haven't encountered this issue yet.Tested using 2 computers with Steam Overlay enabled on Arch Linux
Thank you for the heads up about steam-native-runtime. I'll give that a try after I test other games to see if it'll solve the issue for me. I still want to provide info to make sure this gets addressed for other users.
Make sure you've shutdown steam completely ($ steam -shutdown) before trying $ steam-native as otherwise it'll bring up your existing Steam instance without having any effect.
I haven't ran into this issue in neither Sway nor KDE6 (both uses Wayland).
I have noticed latest steam doesn't cause the bug for me any longer.
xxd /proc/`pidof yourgame`/environ | grep LD_PRELOAD -A2
there is no gameoverlayrenderer.so loaded when the overlay option is disabled in steam now.
So I think its not possible to trigger the bug anymore?
My steam version :
Steam Beta Branch: Stable Client
Steam Version: 1737514353
Steam Client Build Date: Wed, Jan 22 2:35 AM UTC -08:00
Steam Web Build Date: Wed, Jan 22 1:41 AM UTC -08:00
Steam API Version: SteamClient021
Can you confirm?
@Slashic prooved this false information, ignore if you can.
Can you confirm?
Makes absolutely no difference aside the overlay displayed or not in-game, it is still loaded for the game executable be it 32bits or 64bits version.
Besides, i could reproduce the issue with the overlay disabled, the 32bits library deactivated and only the 64bits one loaded.
lsof | grep -i gameoverlay | grep -e steam -e Ys
With option enabled:
steam 47939 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47950 SteamUpda slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47951 pool-spaw slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47952 gmain slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47953 dconf\x20 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47954 IOCP\x20T slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47955 gdbus slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47991 HTMLContr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48019 steam:cs0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48020 steam:dis slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48021 steam:sh0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48022 steam:sh_ slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48023 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48024 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48025 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48028 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48029 steam:gdr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48030 steam:gl0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48043 IPC:CServ slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48044 IOCP\x20T slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48045 IPC:CStea slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48047 CFileWrit slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48049 SteamEngi slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48050 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48051 CHTTPCach slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48052 Controlle slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48053 CSteamCon slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48057 threaded- slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48059 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48060 CSystemMa slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48061 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48074 CFileWrit slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48078 threaded- slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48084 SteamUIWa slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48109 IPC:CStea slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48153 Steam\x20 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48345 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48347 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48368 steam slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48407 SocketThr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48408 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48410 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48442 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48445 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48446 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48884 CNet\x20E slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 49009 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 49841 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 50412 CNet\x20E slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 50413 steam slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 52119 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam.exe 52778 slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
steam.exe 52778 52844 steam.exe slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
steam.exe 52778 52849 steam.exe slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52850 wine_xinp slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52851 wine_sech slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52854 Ysc_dx1:d slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52855 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52856 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52857 dxvk-subm slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52858 dxvk-queu slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52859 dxvk-cs slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52861 dxvk-fram slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52864 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52865 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52866 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52868 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52869 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52870 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52871 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52872 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52873 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52874 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52875 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52876 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52877 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52878 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52879 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52880 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52882 WSI\x20sw slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52883 WSI\x20sw slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52889 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52892 audio_cli slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52893 audio_cli slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52894 wine_dsou slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 52848 52895 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
With option disabled:
steam 47939 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47950 SteamUpda slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47951 pool-spaw slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47952 gmain slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47953 dconf\x20 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47954 IOCP\x20T slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47955 gdbus slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 47991 HTMLContr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48019 steam:cs0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48020 steam:dis slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48021 steam:sh0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48022 steam:sh_ slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48023 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48024 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48025 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48028 steam:tra slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48029 steam:gdr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48030 steam:gl0 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48043 IPC:CServ slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48044 IOCP\x20T slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48045 IPC:CStea slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48047 CFileWrit slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48049 SteamEngi slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48050 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48051 CHTTPCach slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48052 Controlle slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48053 CSteamCon slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48057 threaded- slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48059 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48060 CSystemMa slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48061 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48074 CFileWrit slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48078 threaded- slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48084 SteamUIWa slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48109 IPC:CStea slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48153 Steam\x20 slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48345 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48347 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48368 steam slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48407 SocketThr slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48408 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48410 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48442 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48445 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48446 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 48884 CNet\x20E slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 49009 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 49841 CHTTPClie slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 50412 CNet\x20E slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 50413 steam slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam 47939 52119 CJobMgr:: slash 112r REG 0,50 349308 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so
steam.exe 53820 slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
steam.exe 53820 53885 steam.exe slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
steam.exe 53820 53890 steam.exe slash mem REG 0,39 3291717 /home/slash/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53891 wine_xinp slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53892 wine_sech slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53895 Ysc_dx1:d slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53896 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53897 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53898 dxvk-subm slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53899 dxvk-queu slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53900 dxvk-cs slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53902 dxvk-fram slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53906 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53907 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53908 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53909 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53910 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53911 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53912 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53913 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53914 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53915 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53916 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53917 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53918 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53919 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53920 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53921 dxvk-shad slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53923 WSI\x20sw slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53924 WSI\x20sw slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53926 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53929 audio_cli slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53930 audio_cli slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53931 wine_dsou slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Ysc_dx11. 53889 53932 Ysc_dx11. slash mem REG 0,39 3291701 /home/slash/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so (stat: Operation not permitted)
Steam Beta Branch: Stable Client
Steam Version: 1737514353
Steam Client Build Date: Wed, Jan 22 3:35 AM UTC -08:00
Steam Web Build Date: Wed, Jan 22 2:41 AM UTC -08:00
Steam API Version: SteamClient021
My information was simply incorrect, ignore it.
Its better like you say to use the command lsof than checking environ because there are many processes to check, it gets messy quickly.
lsof /home/YOUR_USER/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so
and
lsof /home/YOUR_USER/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so
confirmed that the library is still loaded even when overlay option is disabled, I need to test further as to why it seems the bug has gone, need more testing time to confirm if it even has.
Update.
Okay, I still experience the bug. Confirmed.
I've left several games running for long lengths of time, and none of them seem to exhibit the issue. My problem might be isolated to the Kingdom Hearts games, which honestly tracks given they just have tons of jutter problems. I know this kind of behavior doesn't happen in Windows, though.
To have everything in one place;
GPU: Nvidia RTX 4070 Super
Steam Version: 1737514353, gotten via pacman
Distro: CachyOS
For reference, here's what I've ran;
Final Fantasy VII REMAKE INTERGRADE (With Gamescope)
AntonBlast (With Gamescope)
Like a Dragon: Infinite Wealth
Shin Megami Tensei V: Vengeance
I'm using Gamescope with the Kingdom Hearts collection as well. I could try playing the KH games run without gamescope. For now I'm going to try playing them with the native runtime version of Steam.
EDIT: Nope, native version still has the problem.
EDITEDIT: I'll also mention, having the Steam overlay turned off via LD_PRELOAD breaks Steam Input for me, contrary to what I've seen mentioned. Controller input stops working entirely in games unless I disable Steam Input in the game's properties. This probably is because of Gamescope.
I have researched/pinned down the more finer details of this issue as far as I could. After enabling logging, Timed out waiting for mutex in PutInternal() is spammed in the log at the time of the lag (~30 min or so of having game active). Research into this error shows that it has occured a few times in the steam client history.
I understand that steam uses shared memory IPC to communicate between threads/processes. Its more likely that some sort of producer/consumer code pattern is used such that both parties interacting with the shared memory have to not overstep each other. It seems that somewhere along the lines one is overstepping thus causing a gradual filling of the shared memory buffer causing one side (the producer/writer in this case) to wait, thus the blocking wait introduces delay in the frame until it quickly times-out.
This means I think the fault might lay in steam executable (it is not reading as fast as the gameoverlay is writing?) more than in the gameoverlay.so as had previously thought. I mean it is the interaction between the gameoverlay/gameprocess and the steam process contestion of said shared memory resource which is the issue. Code issue could be either side.
Of-course as we do not have the source code, my contribution is very little and mostly guessing in the dark, but I share this in hope it speeds up any said effort to get this bug fixed.
Got the same issue with the native linux builds of tf2 and gmod.
(kde plasma 6.2.5; arch linux; 6.12.10-zen1-1-zen; steam-native-runtime)
Disabling the overlay fixes it for gmod, but that also seems to completely disable the new game-recording feature.
I'm using Arch with Kernel 6.12 + Gnome/Wayland + AMD Ryzen 7000 and AMD 7900XTX.
After playing GTFO or Steamworld Heist 2 for ~ 30 Minutes, the games go into "stutter mode". If I then move the mouse, the frame rate drops massivly. When not touching the mouse, the games still run flawlessly.
Is setting LD_PRELOAD still the official/recommended solution for fixing this? (haven't tried it yet)
What exactly is the issue here? What effect does the mouse movement have?
Is setting
LD_PRELOADstill the official/recommended solution for fixing this? (haven't tried it yet)
What exactly is the issue here? What effect does the mouse movement have?
I did that and don't have the same problem with TESO any more. Stable many hours plays.
It just skips loading of the Steam's fancy additions. Have no idea what exactly it do, but why we would need it any way ? :/
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2623797366
The reason for the issue is explained for the most part in this thread, any fix will need to be done by Valve, since the issue is part of the steam client. I don't know if it's correct to call it an "official" fix, but it works, and I have seen Valve employees point people to this thread.
The proposed solution seems not to work for me:
I've added LD_PRELOAD="" to the launch options for Steamworld Heist 2. But after ~30 min of playing, the game started to stutter extremely when moving the mouse. So nothing has changed...
Can you access the in-game overlay when playing the game? If you added LD_PRELOAD="", it should disable the Steam in-game overlay. If you can access it, then try adding %command% at the end of it.
Having the same problem, started after the Steam Game Recording update as well, enabling the overlay fixed the problem.
I've reinstalled my whole OS, twice, in hope to fix this issue, before I found this page. 🤦
I could play about 30 minutes, then, despite FPS counter showing stable 60 FPS, every game felt like 10 FPS. Had to restart it have another 30 minutes of good performance.
After I enabled Steam Overlay the problem is gone. 🥳
Can you access the in-game overlay when playing the game? If you added
LD_PRELOAD="", it should disable the Steam in-game overlay. If you can access it, then try adding%command%at the end of it.
No, the overlay is not available (Shift + Tab does nothing).
Also I have disabled the overlay completely via the GUI: Steam -> Settings -> In Game -> Enable the Steam Overlay while in-game is set to off.
But as I said before, this seems to have no effect on the "game stutters after 30 minutes when moving the mouse"-effect 😉
After I enabled Steam Overlay the problem is gone. 🥳
Wait, what!? ENABLING the overlay was what solved your problem?
@BorisBrock use lsof on so files 2 versions: 64 and 32. Names are here around. Make sure using lsof that when game runs both are NOT loaded.
@BorisBrock yes, enabling steam overlay fixed the issue for me. I had it disabled since... basically forever, because I never used it and it caused some issues few years ago. Then I got Steam update and started to have massive input lags and low FPS when moving mouse after about 30 minutes of play. I thought that there is something wrong with my OS or PC, tried a bunch of nvidia drivers, kernel versions, switched between wayland and X11 and even tried different Linux distros. This issue was grinding my gears for MONTHS.
Then I tried what @rafaberaldo wrote here - I've enabled steam overlay (also set game recording to start on Shift+F11) and after that I was able to have a few-hours play session without any issues.
I haven't done anything with LD_PRELOAD, just enabled steam overlay.
It's been few days now since I did this and everything is still running fine.
Hmm...looks like overflow in consumer/producer pattern than. If overlay is disabled it does not consume, but so still produces. At some moment it is out of memory pre-allocated and starts re-alllocations which do lags. Or pauses before replacing old values in circular buffer.
It is just speculations though.
Wait, what!? ENABLING the overlay was what solved your problem?
Yes, this has been said already, I stopped having this issue as soon as I reactivated the overlay.
These are the 2 most common workarounds in this thread, I would avoid replying with "this worked for me" as these are known workarounds that seem to work for most people who have this issue:
- Either add
LD_PRELOAD="" %COMMAND%to your launch options - Or ENABLE the steam overlay. Yes, the fix is unexpected, but you have to enable to fix it.
There are some other workarounds, if you want to adventure yourself, like chowning and chmodding the 64-bit gameoverlayrenderer.so, like here: https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2604168237
As pointed out on https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2624736540, the actual fix probably needs to be done by valve, as the issue is in the steam client libraries.
(I'm tired of receiving the notifications of people discovering these workarounds again and again)
Can confirm this issue when running CS2 native through gamescope, with the steam overlay ON. Adding unset LD_PRELOAD; does work though, so I will use this workaround for now.
On linux FPS drops to 30 and game lagging or FPS ~160 but game lagging like it 30 and i got spamming message in cs2 console: "[InputSystem] Processing SDL events took 50.1ms". I dont have this issue on windows
I seem to hit either this very issue, or one oddly similar to it... Does anyone here experience abnormally long loading times whenever the "lag bomb" goes off?
On linux FPS drops to 30 and game lagging or FPS ~160 but game lagging like it 30 and i got spamming message in cs2 console: "[InputSystem] Processing SDL events took 50.1ms". I dont have this issue on windows
I tested cs2 with non-beta steam client with steam overlay enabled and with launch option LD_PRELOAD="" %command% and cs2 and dota 2 start working as expected. But today after system updates on my linux system(manjaro) i got cs2 refresh rate bug at fullscreen and fullscreen windowed mode and also average fps became lower by 10. Prev i got cs2 refresh rate bug on debian testing
Prior information about consumer/producer patterns are not accurate, this buffer just resets to 0 when full.
My most recent study of this bug reveals that the steamoverlayvulkanlayer.so library is not loaded into the game process when the overlay is option is switched off, thus the vkQueuePresentKHR() callback-function which it provides means the gameoverlayrenderer.so's VulkanSteamOverlayPresent() frame logic function also does not get called.
(steamoverlayvulkanlayer.so) vkQueuePresentKHR() ->
(gameoverlayrenderer.so) VulkanSteamOverlayPresent() ->
ClearBufferIfFull
This main per-frame function (VulkanSteamOverlayPresent) inside gameoverlayrenderer.so is responsible for clearing the InputEvent Shared Memory when it gets full. So despite the gameoverlayrender.so being fully loaded, its not actually doing anything on a frame basis, only some other hooks like XCheckIfEvent() are functioning (which is what fills the buffer).
Other features that the gameoverlayrender.so is meant to provide whilst the overlay is not enabled will also be missing, so this problem could be the root cause of multiple bugs in issue section currently.
I tested 13th September steam (working version) and the steamoverlayvulkanlayer.so is loaded into the game process when the overlay is toggled off (SteamNoOverlayUI=1).
If you want to see how full your buffer is getting you run this command:
watch -n 1 'xxd -l4 -s4 -g4 -e $(lsof -c0 -w /dev/shm/* | grep 524304 | grep dota2 | grep mem | awk "{print \$9}") | awk "{printf \"%d\n\", \"0x\"\$2}"'
replacing dota2 with the name of your game process.
From the above, I believe the fault might lay within steamclient.so for not loading the vulkan layer?
The InputEvent buffer is 524268 bytes. 36 bytes are used every key input.
Which translates to being full after:
- 60 minutes if 4 input event a second
- 30 minutes if 8 input event a second
- 15 minutes if 16 input event a second
Moving the cursor constantly is a fast way to keep it moving, so shooter games will fill it faster.
The number from the above reading command will wrap around to 0 on a functioning version, whilst also printing to a logfile to confirm it (if STEAM_OVERLAY_LOGGING=1) at /tmp/gameoverlayrenderer.*.log).
Also note, the InputEvent SHM is meant to increase every second of game-time too (by 8 bytes), naturally, without any input. If you don't see the number go up when not doing anything, it means the frame loop is not running, meaning its a quick way to see its still broken if it does not increment.
steamoverlayvulkanlayer.so library is not loaded
I tried chown root:root & chmod -r -w -x on this one, Steam rejected to start. So it tries to load it. Pity. I prefer to cut off everything I don't need to play the game.
Steam fights back files' blockage. Working script (allows to disable updates of Skyrim too, just allow +r):
#!/bin/bash
if [[ ! -f $1 ]]; then
echo "Existing file name is required."
exit 1
fi
sudo chown root:root $1
sudo chmod -r -w -x $1
sudo chattr +i $1
Any news on this topic valve?
I was running into heavy lagging/hitching after ~30 minutes of playing Wasteland 2, on Arch Linux. This was very consistent, and required dozens of restarts to address, yesterday.
Today, I re-enabled the Steam overlay, and I can confirm: it does appear to fix that problem.
This has been confirmed as an upstream problem with Steam by various game devs, at this point I am simply not using Steam for months now (or spending any money there).
I'm not in the habit of asking for progress reports but this has been a ridiculous amount of time for one of the biggest gaming companies in the world: when is this being fixed?
Comments asking for updates or "when is this being fixed" are not going to expedite issue resolution. If anything, they waste the time of the people involved and have the opposite effect.
https://github.com/ValveSoftware/steam-for-linux?tab=readme-ov-file#conduct
Do not repeatedly update an open issue remarking that the issue persists
Also, should your issue not be resolved immediately, it does not mean that a resolution is not being researched or tested. Patience is always appreciated.
Do not repeatedly update an open issue remarking that the issue persists
I didn't, it's the first time I've commented on this issue and I offered the information that multiple game developers have confirmed this is an upstream (Steam) problem.
After the steam update about a week ago, the one that apparently added in additional recording features as well as updated to runtime environments scout, soldier and sniper, both of my linux systems would have issues playing games through proton. I'd notice the odd tiny bit of jitter while playing, but after 20-50 minutes (depending on game and game settings) I'd start getting horrible framerate drops whenever I...
So, to resolve this error, Steam could be reverted back a couple of versions... Just delete this commit and all the following commits. Why persisting if you made a bug that you can not solve?
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2665325007
So, to resolve this error, Valve should essentially remove the work they've put in past few versions..? Is that the solution you're proposing?
A temporary reversion doesn't mean the work is lost completely. They could just reapply the changes, along with a fix, when they find one. And yes, that is a good solution when your software is unusable.
They keep adding things nobody asked for, like "game recording". Which is loaded even if I turn it off. Now I afraid for SSD life / usage too.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2665325007
Steam absolutely could be reverted back a few versions. It doesn't necessarily mean they should do that.
I think that a simple comment from Valve would go a long way, e.g., "We're working on it, expect a fix soon"/"no ETA for now".
No communication is the worst kind of communication, and it does little but upset everyone involved.
This works for me with disabled overlay also
PROTON_USE_WINED3D=1 %command%
But it costs some fps and only for up to DX11
Running into an issue where Monster Hunter Wilds requires steam input and thus requires the overlay for controller support to work, so LD_PRELOAD="" makes the controller stop working. Does anyone have a solution for this? How can I load only steam input?
You could try the second workaround and enable steam overlay.
You could try the second workaround and enable steam overlay.
I tried LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_VALVE_steam_overlay_64 %COMMAND% but that doesn't enable overlay or steam input.
Can't you just enable the overlay in Steam's UI?
On Tue, Mar 11, 2025 at 12:57 PM Sean Behan @.***>
wrote:
You could try the second workaround and enable steam overlay.
I tried LD_PRELOAD=""
VK_LOADER_LAYERS_ENABLE=VK_LAYER_VALVE_steam_overlay_64 %COMMAND% but
that doesn't enable overlay or steam input.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2715076959,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZK72BV6DUBGLNPNO46XBL2T4IZNAVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJVGA3TMOJVHE
.
You are receiving this because you commented.Message ID:
@.***>
[image: codebam]codebam left a comment
(ValveSoftware/steam-for-linux#11446)
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2715076959You could try the second workaround and enable steam overlay.
I tried LD_PRELOAD=""
VK_LOADER_LAYERS_ENABLE=VK_LAYER_VALVE_steam_overlay_64 %COMMAND% but
that doesn't enable overlay or steam input.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2715076959,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZK72BV6DUBGLNPNO46XBL2T4IZNAVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJVGA3TMOJVHE
.
You are receiving this because you commented.Message ID:
@.***>
I tried LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_VALVE_steam_overlay_64 %COMMAND% but that doesn't enable overlay or steam input.
To enable the overlay you have to:
- Remove the launch options or just leave it as
%COMMAND%(leavingLD_PRELOAD=""will force the overlay to be disabled) - Go into
Steam -> Settings -> In Gameand tickEnable the Steam Overlay while in-game
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2715094284
Yes the issue isn't that I can't enable overlay. It's that if I enable it I get the lag spike bug after 40 mins, and without it I can't play with controller. I think it's because monster hunter wilds uses the steam input api
Replying to [#11446 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2715094284)
Yes the issue isn't that I can't enable overlay. It's that if I enable it I get the lag spike bug after 40 mins, and without it I can't play with controller. I think it's because monster hunter wilds uses the steam input api
Yes, turn it ON in Steam UI/Settings. This is reverse - make it work explicit by clicking settings. This will stop bug too as others report.
Bug happens when you have dll loaded + "off" in settings. If both on or both off, it should be no bug.
User already said that enabling the overlay causes the bug. You've asked them to do what originally caused them to come across this issue in the first place.
And no, enabling overlay doesn't solve it. On CS2 (and probably other games), the fix is to disable the overlay. Leaving it enabled will trigger the issue.
personally I've just been removing the overlay related files from steam after opening it and that works as unelegant as it is. Valve please fix
For many here (including me) the bug seems to be related to gameoverlayrenderer.so being loaded while steamoverlayvulkanlayer.so is not. That only happens if you don't override LD_PRELOAD and also disable the steam overlay via the UI. See the analysis at https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200
By enabling the steam overlay via UI (meaning that Shift+Tab opens the overlay while in-game), steamoverlayvulkanlayer.so gets preloaded and the buffer will be cleared when full.
I wonder if the issue with CS2 and maybe some other games is a different bug / caused by a different reason? I can't test this as enabling the overlay fixes the issue for me, but I think that a way to know how related these issues are is: someone that has the issue with the overlay enabled could, with the overlay enabled and confirmed to be working (by pressing Shift+Tab and seeing it appear), 1. check if the shm wraps to 0 (by using the watch command from the linked comment) and 2. check whether both steamoverlayvulkanlayer.so and gameoverlayrenderer.so are loaded (by using lsof)
In the new beta of the Sniper Steam Runtime just released (see https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/Sniper-release-notes#steam-linux-runtime-30-sniper-depot-3020250306120299-steampipe-build-id-17679755) there is:
Improve handling of LD_PRELOAD modules such as MangoHud (steamrt/tasks#595)
Maybe it's related to this issue.
Similar problem.
Occurs after 20 minutes in the game: FPS jumps between the default for me 95-FPS-level and low 30-FPS-level, every few seconds it goes back and forth, it becomes terribly uncomfortable to play.
I play dota2 more than once a week, my problem started recently, no more than two weeks ago.
Didn't help with LAUNCH OPTIONS set to LD_PRELOAD=""
Turning the overlay on and off doesn't help either.
With the overlay turned off, it only loads gameoverlayrenderer.so
With overlay enabled, both are loaded (gameoverlayrenderer.so steamoverlayvulkanlayer.so)
I have not been able to find the conditions under which the problem can be avoided.
I just decided to temporarily stop playing dota2 =)
env
GPU NVIDIA GeForce GTX 1650 Ti
OS ubuntu24.04
GNOME 46
XDG_SESSION_TYPE x11
nvidia-driver 550.120
steam from apt (not snap) https://repo.steampowered.com/steam/ stable steam
Steam Beta Branch: Stable Client
Steam Version: 1741737356
Steam Client Build Date: Tue, Mar 11 23:39 UTC +03:00
Steam Web Build Date: Wed, Mar 12 02:45 UTC +03:00
Steam API Version: SteamClient021
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2719284362
game launch settings: LD_PRELOAD="" %command% -novid -console +exec autoexec.cfg
and steam overlay enabled, no problems on manjaro xorg xfce amdgpu polaris vulkan-radeon
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2719284362
Then this is not the same bug. I think recent dota patches can explain
what you are experiencing. Its unrelated I would most assume.
Remember:
lsof /home/YOUR_USER/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so
to confirm that LD_PRELOAD="" prevents gameoverlayrenderer.so from being loaded by the dota process. Which also confirms the bug will not be present.
Further:
watch -n 1 'xxd -l4 -s4 -g4 -e $(lsof -c0 -w /dev/shm/* | grep 524304 | grep dota2 | grep mem | awk "{print $9}") | awk "{printf "%d\n", "0x"$2}"'
Will output nothing when gameoverlayrenderer.so is not loaded, because the shared memory will not be used (LD_PRELOAD=""). When gameoverlayrenderer.so is loaded with overlay enabled, the number will reset to 0 when it gets full. The bug is specifically when the number does not reset to 0 (caused by steamoverlayvulkanlayer.so not being loaded when overlay is off).
I have an update. I've turned the Steam Overlay on as people mentioned here it fixes the problem and for some time it was OK. But since I've switched to GE-Proton9-25 the game (Overwatch 2) is not just lagging after 5-40 mins - now it completely freezes and crashes. LD_PRELOAD or deleting gameoverlayrenderer.so fixes the problem again. Weird...
I have an update. I've turned the Steam Overlay on as people mentioned here it fixes the problem and for some time it was OK. But since I've switched to GE-Proton9-25 the game (Overwatch 2) is not just lagging after 5-40 mins - now it completely freezes and crashes. LD_PRELOAD or deleting gameoverlayrenderer.so fixes the problem again. Weird...
Interesting, I've been using GE-Proton9-11 for Overwatch 2 for a while as all of the official versions have been giving me terrible FPS for a long while, but a week or two ago I started getting this same freeze & crash. One of the times, I managed to focus a Wine (Windows) window in that was behind the frozen game and it had "Your rendering device has been lost" error. I assumed it was related to an Overwatch update or something I changed (I had recently experimented with other proton versions again) so I just stopped playing.
but a week or two ago I started getting this same freeze & crash.
Well, I guess maybe the change that started causing the crash is not in GE-Proton version but in latest Overwatch 2 patch, or latest NVidia drivers update. Yet I can confirm that with Steam Overlay enabled and with gameoverlayrenderer.so loaded there's a guaranteed time-bomb crash with black screen and "Your rendering device has been lost" error instead of good old lag spike now. And with workarounds (I've automated the deletion of gameoverlayrenderer.so files before game loads) it works just fine. So it's the same problem but it manifests in other way now.
Interesting, I've been using GE-Proton9-11 for Overwatch 2 for a while as all of the official versions have been giving me terrible FPS for a long while, but a week or two ago I started getting this same freeze & crash. One of the times, I managed to focus a Wine (Windows) window in that was behind the frozen game and it had "Your rendering device has been lost" error. I assumed it was related to an Overwatch update or something I changed (I had recently experimented with other proton versions again) so I just stopped playing.
I've had to delete the wine prefix for Overwatch 2 when upgrading from GE-Proton9-11, because I would get terrible fps as well and that fixed it. Maybe it's the same issue for you?
The ow2 thing is a bit offtopic, but note a common thing to do in Overwatch is to switch Reduce buffering to off and on again. Not sure which bug this is, but it helps to reset performance. You need to do that in all proton versions.
switch Reduce buffering to off and on again
With OW under Proton you can actually just Alt+Enter out and back to fullscreen (or vice-versa). This also resets the buffers and performance, but saving some time from digging into menus. Doesn't work same way in Windows.
Thanks y'all and yeah, this ended up being very off topic. By deleting the prefix (I thought I tried that before, huh) I was able to get high FPS in Proton 9.0-4 and yeah, it didn't freeze with the overlay on and working, so I guess that's caused by a specific interaction with the latest Overwatch, latest gameoverlayrenderer.so and Proton GE.
Identical to what I see in OW2. Runs perfect for half an hour or so, then has issues.
While actually playing and moving myself, the game goes haywire, the symbol claims its lagging (but I see the same issue in Kovaaks which is offline) and it tries to claim its still 100 fps while it is chopping all over the place. But if it's playing a killcam (in the same game) it doesn't drop a frame. Moment i have control and move again it starts lagging.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2727176644
it runs fine in killcams because it's related to mouse movement
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2727176644
I assume you have the overlay disabled on Steam. Have you tried either:
- ENABLING the overlay by going into
Steam -> Settings -> In Gameand checkingEnable the Steam Overlaywhile in-game, or - Adding the following to OW2's launch options:
LD_PRELOAD="" %COMMAND%
Replying to [#11446 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2727176644)
I assume you have the overlay disabled on Steam. Have you tried either:
1. ENABLING the overlay by going into `Steam -> Settings -> In Game` and checking `Enable the Steam Overlay` while in-game, or 2. Adding the following to OW2's launch options: `LD_PRELOAD="" %COMMAND%`
The LD_preload workaround seems to be working for me, going to test it more later but got past the half hour mark with it.
The overlay I had turned off a while ago, think it helped performance. Turning "Nvidia reflex" to "enabled" but not boost seemed to have the biggest impact on making the game "feel" correct for me.
And before enabled "ld_preload", the game did feel 99% perfect. It would just fill its pants after half an hour or so (seems to fill quicker the higher your texture quality is too, had like 2 hours on lowest settings and half an hour on medium).
(seems to fill quicker the higher your texture quality is too, had like 2 hours on lowest settings and half an hour on medium)
See the analysis at https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200. In theory, the time it takes is related to how many inputs (mouse movement, key presses) you make.
I've been getting the "Processing SDL events took" spam in my console recently after about 1.5hrs+ of CS2. I have to quit and reload the game so far as I am unsure of a proper fix.
I'm also having this issue when running Trackmania when opening with gamescope. Using the LD_PRELOAD workaround is not an option, because my controller (an generic dinput) does not work with it, so I'm tied up to using the subpar windowed fullscreen without gamescope (which does fill all the screen btw). The -e flag also did nothing for me.
I'm having this issue on CS2, suddenly starts lagging, SDL events took 50.1ms everytime, every 30 minutes of playing or so
Every game lags after lags after 20 minutes if overlay is enabled, and if i enable it the main steam window doesnt open after some time playing
From my understanding, disabling the overlay should be a workaround to this issue. What I noticed is that if I enable the overlay, play a game until the lag spikes appear, exit the game and disable the overlay in steam settings and then start the game again, the stutters still appear after around 30-40min of play.
I experienced this while playing marvel rivals and black ops 3 zombie mode. I've added the LD_PRELOAD env var to my launch options and this seems to have fixed the issue for those games. The weird part is that I expected for the issue to disappear just by disabling the overlay.
Here is my hardware spec:
- CPU: 7800X3D
- GPU: 7900XTX
- Compositor: Hyprland 0.48.1
- Kernel: 6.14.0
- Mesa: 25.1.0-dev Mesa-Git
- Proton: Experimental and GE Proton 27
- Steam: Beta and Stable
From my understanding, disabling the overlay should be a workaround to this issue. What I noticed is that if I enable the overlay, play a game until the lag spikes appear, exit the game and disable the overlay in steam settings and then start the game again, the stutters still appear after around 30-40min of play.
No, loading the .so causes the stutters. Just disabling the overlay isn't enough, you have to prevent the game from loading the steam overlay .so file. The issue description has a link to the workaround, but just in case those steps are hard to follow:
- Right click on the game you want to fix
- Go to
Properties - Under
Launch Options, type:LD_PRELOAD="" %command%
As far as I know, you have to do this for every game you want to play without stutters.
Thank you so much for the workaround, I posted at https://forums.developer.nvidia.com/t/570-release-feedback-discussion/321956/493 this same message and they brought me here
Using this latest driver with the 5090, after 45 minutes of playtime or more, I think all games but will limit to the ones I saw the same issue in: incredible stuttering lag.
After about 45 minutes to an hour games like goat simulator 3,
god of war (1 and 2),
gta 5 enhanced,
kingdom come 2,
the finals,
marvel rivals,
borderlands 3
and cs2.
All of these games you can’t play them longer than 45 to an hour straight now before a sudden stuttering attack happens. The timing is always consistent (45 to 60 minutes).
I've been having this issue as well, and it's rather hard to search for online! I thought it was just related to Unreal Engine games (as that's what I've been playing when I noticed it) and was going down endless trails of forum posts trying various things out.
I think the easiest option for me is just to re-enable the overlay, but the LD_PRELOAD fix also works as well.
Im having almost exactly the same issue, happening at the 37 minute mark very consistently. the LD_PRELOAD=" " has not worked for me unfortunately, neither has disabling steam overlay or steam recording. I get this in both wayland and X11.
Enabling the steam overlay is the common solution in this thread, not
disabling it.
On Mon, Apr 14, 2025 at 8:13 AM Valkyronix @.***> wrote:
Im having almost exactly the same issue, happening at the 37 minute mark
very consistently. the LD_PRELOAD=" " has not worked for me unfortunately,
neither has disabling steam overlay or steam recording. I get this in both
wayland and X11.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2800688091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATICPEAXY66SACRYNE7NRT2ZNNYTAVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBQGY4DQMBZGE
.
You are receiving this because you were mentioned.Message ID:
@.***>
LunarPidgeon left a comment (ValveSoftware/steam-for-linux#11446)
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2800688091Im having almost exactly the same issue, happening at the 37 minute mark
very consistently. the LD_PRELOAD=" " has not worked for me unfortunately,
neither has disabling steam overlay or steam recording. I get this in both
wayland and X11.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2800688091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATICPEAXY66SACRYNE7NRT2ZNNYTAVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBQGY4DQMBZGE
.
You are receiving this because you were mentioned.Message ID:
@.***>
glad i found this thread, shemelody you are a saint! i get like 240 fps with frame acceleration playing marvel rivals. but routinely after about 30-45 minutes of playing the game, it stutters beyond belief. seems apart from the command fix, relaunching the game stabilizes it for a brief time, before happening again.
I think this is also related to the version of proton running.
The suggested workaround of LD_PRELOAD worked fine for a week or so, however this week Proton-GE 26 just broke down completely, I could only play 2-5mins before FPS would drop to <10.
I tried 25,24,23,22 with no luck. I reverted further back to Proton-GE 14 and that works fine.
I think this is also related to the version of proton running.
The suggested workaround of LD_PRELOAD worked fine for a week or so, however this week Proton-GE 26 just broke down completely, I could only play 2-5mins before FPS would drop to <10.
I tried 25,24,23,22 with no luck. I reverted further back to Proton-GE 14 and that works fine.
The workaround still works for me. It sounds like you're describing a different problem.
I think this is also related to the version of proton running.
The suggested workaround of LD_PRELOAD worked fine for a week or so, however this week Proton-GE 26 just broke down completely, I could only play 2-5mins before FPS would drop to <10.
I tried 25,24,23,22 with no luck. I reverted further back to Proton-GE 14 and that works fine.The workaround still works for me. It sounds like you're describing a different problem.
Is there a way I can 100% verify this is my problem and not something else or a red herring?
I can confirm having the overlay does nothing on a 4060, 4090 or 5090 using either Ubuntu 24.04 or 25.04. But adding
LD_PRELOAD="" %command%
To the launcher options does in fact work. At least the games tested were Goat Simulator for more than 2 hours, Kingdom Come 2 (Almost 3 hours) and all Spiderman 1, Miles Moralres and Spiderman 2.
Is this a steam issue, proton issue or driver issue?
Steam issue. Scroll up, there are some pretty detailed explanations.
I'm pretty sure this is the same issue I am having, and the timeline makes sense.
Late last year I was playing Fallout 76 without issue, but then after they released a big update, it soon became unplayable. After 20-40 minutes of gameplay, the fps dropped to sub-20, and it was a stutter-y mess that never recovered. I attributed this to the update and to FO76 being poorly optimized in the first place. I have tried to play it multiple times since then, but the problem persists.
Fast-forward to a few weeks ago, when I installed the Witcher 3 (DX11). The game was fine for about half an hour, then right on schedule, the fps tanked. I enabled MangoHud with the frame time graph and could see the game flatline. Before performance completely tanked, the fps was not consistent, and the game stuttered often.
For a comparison, I tried playing these games on two completely different systems:
- Fedora 40 with an NVIDIA GPU on Wayland KDE
- Ubuntu 22.04 with an AMD GPU on Wayland GNOME
The results were the same. Neither game is playable after a certain amount of time.
These performance issues do not happen in every game. Fallout 76 and The Witcher 3 have issues, but Metro Exodus, Prey (2017), DOOM (2016), Civilization VI, and Batman: Arkham Knight were fine.
LD_PRELOAD="" %command% seems to have solved my issues in the Witcher 3. I played 4 hours tonight on Fedora and the game ran great! I will have to go back and test Fallout 76.
I just had this issue in Expedition 33 yesterday. Was playing it fine for many hours in previous sessions but then I enabled mangohud in gamescope, played around with the game settings to get few more fps and a few minutes later I had the frame time spikes.
LD_PRELOAD="" caused other issues for me, so I replaced gameoverlayrenderer.so with an older version instead, which seems to have done the trick. The overlay is glitching out, but at least the game works fine. Maybe there is a version that works but doesn't have the bug, but I can't find a list of official versions.
I just had this issue in Expedition 33 yesterday. Was playing it fine for many hours in previous sessions but then I enabled mangohud in gamescope, played around with the game settings to get few more fps and a few minutes later I had the frame time spikes. LD_PRELOAD="" caused other issues for me, so I replaced gameoverlayrenderer.so with an older version instead, which seems to have done the trick. The overlay is glitching out, but at least the game works fine. Maybe there is a version that works but doesn't have the bug, but I can't find a list of official versions.
Oh my could this be blaming nvidia drivers but it was steam all along.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2814256415
They have 0 clue about the issue you're having. This does sound like the exact same issue (i.e. the memory time bomb)
I use mangoHUD to monitor components' statistics and noticed that in my configuration Ubuntu 24.04, LTS RX-3700, RX 4060, when the lag happens GPU clocks drop from 2805 MHz to 2790, also having the fps graph present a "swarm of spikes" and the overall gaming FPS are dropped significantly (around 50%).
I wanted to report that I am also experiencing this issue now
It started this week with Borderlands 3 and now i get it today with Dishonored 2.
Im on Cachy OS, Kernel 6.14.5-3, Mesa 25.0.5, and tried the latest proton experimental and the latest Proton GE
This issue does not effect the steam deck
Its crazy that this issue has reoccurred, but many are not able to replicate the issue
Can confirm this still happens. Tested in Naraka Bladepoint and Wuthering waves. Severe stuttering starts to happen after around 30mins of gameplay.
Using CachyOS with latest kernel 6.14.5-3, along with proton-cachyos.
Amazed by how long this issue has persisted, almost for past 7-8 months or more at this point. Needs to be addressed quickly.
I ran into this with CS2 as well now.
i own a high end system with the sapphire 7900xtx nitro, a AMD 9 9950x3d. after around 30 mins of game play the game becomes a stuttery mess and i have to restart. normally i have buttery smooth frames at 4k.
Amazed by how long this issue has persisted, almost for past 7-8 months or more at this point.
This issue does not effect the steam deck
You guys may be onto something.
Have the same problem with Dota 2. Every game, right between 24 and 25 minute mark FPS drops to absolutely unplayable. Interesting thing is, in-game FPS counter still shows values well above 60, but it doesn't look like more than 10-15 FPS max.
Edit. After testing for couple games, seems that LD_PRELOAD="" helps. Thanks!
I did not get the stutter bomb problem when using env SDL_VIDEODRIVER=wayland %command%.
Is this issue something people notice only when actually using KBM? I found this thread because I am running into lag issues after playing for a while, but only when I move my mouse around. I don't actually have any lag spikes whatsoever no matter how long my session is if I use a controller. However to be clear the lag only happens when I actually move my mouse. If I stand still with no input then everything runs fine.
@Kharn501 See this comment https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200
A Xinput/event callback function defined in a library is active when it shouldn't be. So a buffer is filled with the events, but the buffer is never cleared because it doesn't expect it to be filled.
So yes, it makes perfect sense that you are experiencing it when only you are applying X input events. X input events == fill the buffer to full capacity == experience lag at full capacity because of a function blocking, specifically a mutex access for the Shared Memory buffer file.
If anything I have the recording feature disabled.
Same for the steam overlay.
Same effect here, after ~~30min heavy FPS stutter. Steam Overlay and Screen Recording is off.
Running on Debian 6.9.7-1~bpo12+1 (2024-07-03) x86_64 GNU/Linux. One thing is strange when i play the same game with an xbox controller the FPS is stable all the time. No stutter at all. It only happens when using the keyboard/mouse.
Hey all - thanks for the reports. We believe we have a fix for this issue, it hasn't made it's way through our release pipeline yet but I'll update here when we do.
@TTimo our hero! :D
Lovely news. Thank you for breaking the silence and giving us some information
Thanks to this report it is getting a fix.
https://github.com/ValveSoftware/SteamOS/issues/1882
Turned out same issue was affecting Deck too, then this issue got an assignment and getting a fix now.
Remember, if you want issues to be fixed make sure it affects Steam Deck too.
I already wrote about this, addition. I have exactly this problem with the FPS drop from a stable 60 to 20-25 frames in each game, at least once per game, appeared after patch 7.39. Moreover, it is fixed every time by re-entering the game, but it happens in absolutely every game after patch 7.39. I play with a mouse, keyboard and a monitor on a Steam deck Oled
reply to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2896864603
Thanks for the info, has this been merged into the beta opt in of steam?
I has the exact same issue with Verdun, Far Cry 3, Far Cry 5, Stalker Anomaly, and any other game that I keep open for more than 30 minutes
reply to [#11446 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2896864603)
Thanks for the info, has this been merged into the beta opt in of steam?
Don't think so. I'm on the beta opt in and it's still a bug. Gets fixed with the launch options, but it's annoying to have to write them for every game.
reply to [#11446 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2896864603)
Thanks for the info, has this been merged into the beta opt in of steam?
Don't think so. I'm on the beta opt in and it's still a bug. Gets fixed with the launch options, but it's annoying to have to write them for every game.
Script which blocks loading of SO and steam updates too:
#!/bin/bash
cd /home/alex/.steam/steam
function lock {
if [[ -f ./gameoverlayrenderer.so ]]; then
sudo chmod -r -w -x ./gameoverlayrenderer.so
sudo chattr -i ./gameoverlayrenderer.so
else
echo "There is no file."
fi
}
pushd ubuntu12_32
lock
popd
pushd ubuntu12_64
lock
popd
Reverse script which unlocks it:
#!/bin/bash
cd /home/alex/.steam/steam
function unlock {
sudo chattr -i ./gameoverlayrenderer.so
sudo chmod +rw ./gameoverlayrenderer.so
sudo rm ./gameoverlayrenderer.so
}
pushd ubuntu12_32
unlock
popd
pushd ubuntu12_64
unlock
popd
Change patches on 1st lines.
unlock-updates - run steam - close steam - lock updates - run steam -- so will not be loaded at all anywhere.
Repeat cycle when you feel you want to get some updates. It will try to update on each run though, because of this SO mismatch check and cancel update because it can't.
I'm not sure if this is still a big issue. However, I did a few things and it now works for me.
I use the following:
Arch Linux
AMD Ryzen 9 3900X 3.8 GHz 12-Core Processor
Gigabyte X570 AORUS ELITE WIFI ATX AM4 Motherboard
G.Skill Trident Z Neo 32 GB (4 x 8 GB) DDR4-3600 Memory
Seagate Barracuda 1 TB 3.5" 7200RPM Internal Hard Drive
Western Digital Caviar Blue 1 TB 3.5" 7200RPM Internal Hard Drive
Toshiba 2 TB 3.5" 7200RPM Internal Hard Drive
Crucial MX500 2 TB 2.5" Solid State Drive
Sapphire Radeon RX 6900 XT 16 GB NITRO+ Video Card
Lian Li PC-O11 Dynamic XL
EVGA SuperNOVA T2 750 W 80+ Titanium Certified Fully-Modular ATX Power Supply
AOC G2460PF 24.0" 1920x1080 144 Hz Monitor
LG 27GL850-B 27.0" 2560x1440 144 Hz Monitor
Few other things like fans and stuff.
Searched through my Library for Proton Experimental
After that I right clicked and went to properties. Then selected the Betas tab on the left hand side. Made sure it was set to [none]
I then went into settings in Steam.
From here I did a few things. Goto Compatibility and select Proton Experimental and make sure it is enabled for all other titles.
Then just for the lols I turned on Game Recording (Manual) and Steam Overlay.
I'm not sure if this weird bizarre amount of things will help others. However, I hope it does. This issue has forced me to use my Windows installation which I hate. I was able to play for about an hour before I wanted to do something else.
Thanks for coming to my tedtalk.
A Wild Huck.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2925504126
I think you may be onto something specifically with the enabling manual game recording setting instead of having it disabled. I kept all other settings the same but only changed that setting and I haven't seen any lag issues when using KBM in Oblivion, Expedition 33, or Witcher 3 after well over an hour of playtime in each. I cannot be sure if these are just games that are exceptions to this issue or not because I've just been using controller for weeks, but I felt like this was basically affecting anything I played for the most part before I moved to controller.
Yakuza 0 was the last game I know for sure was being affected by the lag issue so I can try to test it tomorrow to see if the fix worked there as a true like to like experiment.
EDIT: looks like after 30-40 minutes of Yakuza 0 there is still no lag so until the update comes out of beta I'm going to assume enabling manual game recording is the interim fix if you want to keep the overlay enabled.
Adding my comment here. I have the same issue. I tried every version of Proton, none were successful.
I am, as I am writing this, scanning through the entire issue for fixes.
Reminder: if all you want to add to the bug is "oh yeah i had that issue too and the solution helped me" please just click the thumbsup in the initial post in this thread. those comments do not add any more useful information to the issue. Also a fix is already being in the pipeline to be released hopefully soonish.
Thank you in advance.
seems like latest steam client beta has the fix
Fixed periodic gameplay lag and freezing in games using Vulkan rendering when running with Steam Overlay disabled.
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/545610012180874686
seems like latest steam client beta has the fix
Fixed periodic gameplay lag and freezing in games using Vulkan rendering when running with Steam Overlay disabled.
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/545610012180874686
Would closing and re-opening the Steam client trigger an auto update as I currently have it opened?
Top Left > Steam > Check for Steam Client Updates
(assuming you're in the steam client beta, else you need to opt-in by going to: Top Left > Steam > Settings > Interface ; "Client Beta Participation" & Select "Steam Beta Update")
This doesnt fix it for me using Manjaro KDE witth Wayland and Gamescope
I am still getting the issue as well. Tested With Doom Eternal. KDE Wayland, Gamescope with RTX 4080.
Steam Beta Branch: Steam Beta Update
Steam Version: 1748900261
Steam Client Build Date: Mon, Jun 2 16:21 UTC -08:00
Steam Web Build Date: Mon, Jun 2 14:21 UTC -08:00
Steam API Version: SteamClient022
Steam Version: 1748900261
Same version plus Proton Experimental. Starcraft 2 works smoothly more than 1 hour without LD_PRELOAD="".
Seems fixed for me.
I can confirm that the issues I was having with using the Steam Overlay with Gamescope have been addressed by this update.
Steam Version: 1748900261
Same version plus Proton Experimental. Starcraft 2 works smoothly more than 1 hour without LD_PRELOAD="". Seems fixed for me.
I am using Proton Experimental as well. I have run it 3 today and all 3 times after 25 minutes it started up the sawtooth frametime stutter.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2937822138
I am on a RTX 4080. Are you on Nvidia or AMD?
Steam Beta Branch: Steam Beta Update Steam Version: 1748900261
Still seeing this issue with the latest Steam Beta update and both ProtonGE and proton-cachy. Starts happening a few seconds after 25 minutes of gameplay.
Hello @jeisom, can you clarify what you mean by 'KDE Wayland, Gamescope with RTX 4080', and test a more simple setup first.
If you run Doom Eternal on KDE Wayland (no Gamescope), that is kwin compositor + XWayland with Proton Experimental, are you reproducing the hitches?
(You need to be running the latest Steam beta of course, but that seems reasonably clear you are on the right version from your original post)
Hello @jeisom, can you clarify what you mean by 'KDE Wayland, Gamescope with RTX 4080', and test a more simple setup first.
If you run Doom Eternal on KDE Wayland (no Gamescope), that is kwin compositor + XWayland with Proton Experimental, are you reproducing the hitches?
(You need to be running the latest Steam beta of course, but that seems reasonably clear you are on the right version from your original post)
I just tested without gamescope and it stills does it. The average fps dropped from 75(screenlocked) to 60 and the lows weren't as bad so it was more playable. I didn't screenlock it. GPU load before the 25min threshold was around 70% and after 100%. I didn't change anything other then disabling gamescope and gamescope didn't screenlock the fps before.
screenlock=locking max framerate to screen refresh rate.
I have a RTX 4080(575.57.08) on Plasma Wayland(6.3.91). Before running Doom Eternal in Gamescope for the HDR support.
Arch linux
I can test on Plasma 6.3.5 if you'd like.
@jeisom thanks, and you had the steam overlay disabled via the steam UI for the title, correct? No forced LD_PRELOAD="" workarounds?
I just want to make sure it's not a different issue that also happens to start after some gameplay duration before we look into it again.
The issue we are addressing here is specifically for Vulkan titles (Doom Eternel over Proton uses Vulkan, so that fits), when the steam overlay has been disabled in the steam UI.
@TTimo I believe there are at least a couple issues relating to lag spikes that can be fixed with the LD_PRELOAD="" workaround.
I see what I could describe as a "lag bomb" after 25 minutes but the steam overlay is enabled. The frame time graph looks like a heartbeat on an ECG. This issue is what I thought this was related to but I feel like I might be mistaken.
At this point, if you are still having issues, I recommend giving us all the information. System settings, programs used, settings in those programs, solutions attempted. The more information we have the better.
The issue with Steam was verified as fixed by some but not all with the beta participation. Furthermore, my fix of putting the steam recording on manual also fixed the issue. Again this was for some not all. For some reason the issue isn't consistent as people with the same builds and settings can still have different issues.
From the sound of it some people have a framerate issue with mouse movements. This could be something related to mouse drivers or something like that. However, I no longer have the issues.
From the sound of it some people have a framerate issue with mouse movements.
My understanding is that it's this same issue, as it's amplified by input, see the analysis at https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200
I had it and it had the exact same symptoms (only after X minutes, vulkan / DXVK games) and it aws fixed by the same things (enabling overlay or LD_PRELOAD=""). I haven't checked yet whether the beta fixed it or not for me (I have been playing with the overlay enabled since), but I imagine it has.
The issue doesn't appear to be fixed. I have removed LD_PRELOAD="" from the launch options, on the latest Steam beta, and the lag is there after 35-45 minutes. Steam Overlay is disabled, Game Recording is off.
- Governor of Poker 2: Premium Edition,
gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f -- %command%, Proton 9.0-4 - X-Blades,
gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f -- %command%, GE-Proton9-23
I also tested Governor of Poker 2: Premium Edition without any launch options and with the latest Proton Experimental on Steam (i.e. Xwayland without gamescope setup), all on the same Steam beta version. In this scenario, the lag appears to be lesser and can actually disappear as long as the mouse isn't used (I totally forgot to test the keyboard though, but I'd assume it will also trigger the lag in a similar fashion).
I believe toggling the overlay setting on the beta version will do nothing in either scenario in relation to the lag (only LD_PRELOAD="" has ever fixed the lag for me and I assume this still applies to the beta version as well).
Steam Beta Branch: Steam Beta Update
Steam Version: 1748900261
Steam Client Build Date: Mon, Jun 2 11:21 PM UTC -08:00
Steam Web Build Date: Mon, Jun 2 9:21 PM UTC -08:00
Steam API Version: SteamClient022
Arch Linux, Wayland, swaywm.
I believe toggling the overlay setting on the beta version will do nothing in either scenario in relation to the lag
So you believe it has made it worse? Yikes. If it affects when overlay is on, its much more users affected than prior.
On Thu, Jun 5, 2025 at 7:00 AM Dimitar Yurukov @.***>
wrote:
mscalindt left a comment (ValveSoftware/steam-for-linux#11446)
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2942876144The issue doesn't appear to be fixed. I have removed LD_PRELOAD="" from
the launch options, on the latest Steam beta, and the lag is there after
35-45 minutes. Steam Overlay is disabled, Game Recording is off.
- Governor of Poker 2: Premium Edition, gamescope -w 1920 -h 1080 -W
1920 -H 1080 -F fsr -f -- %command%, Proton 9.0-4- X-Blades, gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f --
%command%, GE-Proton9-23I also tested Governor of Poker 2: Premium Edition without any launch
options and with the latest Proton Experimental on Steam (i.e. Xwayland
without gamescope setup), all on the same Steam beta version. In this
scenario, the lag appears to be lesser and can actually disappear as long
as the mouse isn't used (I totally forgot to test the keyboard though, but
I'd assume it will also trigger the lag in a similar fashion).I believe toggling the overlay setting on the beta version will do nothing
in either scenario in relation to the lag (only LD_PRELOAD="" has ever
fixed the lag for me and I assume this still applies to the beta version as
well).Steam Beta Branch: Steam Beta Update
Steam Version: 1748900261
Steam Client Build Date: Mon, Jun 2 11:21 PM UTC -08:00
Steam Web Build Date: Mon, Jun 2 9:21 PM UTC -08:00
Steam API Version: SteamClient022Arch Linux, Wayland, swaywm.
—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2942876144,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATICPCBTGJOZ4BGG4AYKP33B7MJDAVCNFSM6AAAAABRQ2MRUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBSHA3TMMJUGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>
The update has fixed the issue for me, tested on overwatch 2 with gamemoderun %command% with Hyprland compositor.
This is the commit describing my system config when i tested this (nixos configuration) b5c0e658529898a14d0d13c56b0dbe952a553331
I am confused about this fix from Valve. How is that the fix is for when the Steam Overlay is disabled if people reported it being due to the Steam Recording/Replay feature, where it needs the overlay to be enabled to function?
I am confused about this fix from Valve. How is that the fix is for when the Steam Overlay is disabled if people reported it being due to the Steam Recording/Replay feature, where it needs the overlay to be enabled to function?
Producer-consumer problem. Library loads into the game (LD_PRELOAD) and starts to produce records. But nobody consumes it because disabled. Buffer overflows and starts to grow, which causes lags.
So solutions are: enable consumer or prevent library loading.
Got it; thanks for the analogy! So, if I understand it correctly, the lag spike does not happen for people with the Steam Overlay enabled (the default setting)?
I've personally not felt this lag spike and I have it enabled.
Got it; thanks for the analogy! So, if I understand it correctly, the lag spike does not happen for people with the Steam Overlay enabled (the default setting)?
I've personally not felt this lag spike and I have it enabled.
Yes, probably they don't have lag. However, "producer" still works, it makes bottle-neck in this place. On low end machines it may be slow just because it is present. I think, every mouse message in the system which had to go in parallel to different destinations will pass through this place. At least, that is how it works on Windows. Not sure details on Linux.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2941418590
I had no forced workarounds, but I checked and found I'd set some PROTON/HDR/dxvk environment variables, so I unset them uninstalled some vulkan layers that were installed as well. After testing this outside of gamescope I wasn't able to reproduce. No idea if any of that did anything or if it decided to "work"
Also, gamescope seems to have broken on me too with DoomE running at half refresh when not getting user input. So no hdr. No idea what is going on there. It was doing it without gamescope too at one point. I don't think I did anything to fix it without gamescope, but..... a problem for another day. So technically I can't reproduce there either at least in the same way.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2942876144
I decided to do some setup tests (of course not thorough/complete, since there are more than 20 feasible setups that could be tested and we are not even factoring native Wayland emulation in them—all is done on Xwayland)... Steam Overlay and/or Game Recording are disabled unless noted otherwise in each test.
For context, I believe Governor of Poker 2: Premium Edition (GoP2PE), a flash game's emulation, is 'OpenGL -> Proton passthrough', and X-Blades's emulation is 'DX9 -> DXVK via Proton' (confirmed with DXVK_HUD).
More tests can be done if needed, but I think lots of information has mostly been captured. And of course, all problems mentioned get resolved by LD_PRELOAD="" (reasonable assumption for all tests, verified on critical ones).
Steam Stable:
- (1) XBlades,
gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f -- %command%, GE-Proton9-23. Strong drastic lag spikes after ~30 minutes, irrelevant of keyboard/mouse input. - (2) XBlades, no launch options, GE-Proton9-23. Strong and really bad drastic lag spikes after ~35 minutes only with mouse/keyboard input.
Steam Beta:
- (3) GoP2PE,
gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f -- %command%, Proton 9.0-4. Strong drastic lag spikes after ~30 minutes, irrelevant of keyboard/mouse input. - (4) GoP2PE, no launch options, Proton Experimental. Lag spikes after ~44 minutes only with mouse/keyboard input, mouse input alone creates much more significant spikes (but keyboard-induced spikes can be noticed/tracked). Important clarification: Requires active overall input to experience. Conflicts with test 9 (Proton/Steam possible factors to blame unless the beta update didn't intend to fix the issue here in test 4).
- (5) GoP2PE, no launch options, Proton Experimental, Steam Overlay enabled. No lag of any kind even after 60 minutes, but like tests 4/6, it might've needed more overall input.
- (6) GoP2PE, no launch options, Proton Experimental, Game Recording enabled. No lag of any kind even after 60 minutes, but feels weird in fluidity if anything. Maybe it needed more overall input (game was mostly put in pause menu) throughout the 60 minutes for the spikes to manifest.
- (7) XBlades,
gamescope -w 1920 -h 1080 -W 1920 -H 1080 -F fsr -f -- %command%, GE-Proton9-23. Strong drastic lag spikes after ~30 minutes, irrelevant of keyboard/mouse input. - (8) XBlades, no launch options, GE-Proton9-23. No lag of any kind after 45 minutes.
- (9) XBlades, no launch options, Proton Experimental. No lag of any kind even after 70 minutes (active overall input). Conflicts with test 4.
Steam Beta Branch: Stable Client
Steam Version: 1747701111
Steam Client Build Date: Mon, May 19 9:51 PM UTC -08:00
Steam Web Build Date: Tue, May 20 2:21 AM UTC -08:00
Steam API Version: SteamClient022
Steam Beta Branch: Steam Beta Update
Steam Version: 1748900261
Steam Client Build Date: Mon, Jun 2 11:21 PM UTC -08:00
Steam Web Build Date: Mon, Jun 2 9:21 PM UTC -08:00
Steam API Version: SteamClient022
Significant conclusions:
- Gamescope always triggers input-irrelevant lag spikes after 25-40 minutes for some reason (unless
LD_PRELOAD=""is used, of course). It might mask the actual issue when used. Seems very related to an own issue: https://github.com/ValveSoftware/gamescope/issues/163 - The beta version actually fixes the issue, but only partially (fixed for XBlades, not fixed for GoP2PE). Proton always loads Vulkan-related libraries opportunistically (default Proton behavior, I think, just stating); an environment scenario or something of the sort not considered from the beta fix, intentionally or not?
- As noted by the tests, I observed (at some point later in testing the setups) that the lag spikes related to input can only manifest if there has been enough past input. For clarification, if the game has not been interacted with, lag spikes might not be seen (probably not until enough overall input is accumulated; warrants a test, but oh my, this is all just so annoying); I cannot reproduce test 4 if the game has not been interacted with, even if the game stays idle for hours and only has been interacted with for a minute or two at a given hour. This lag condition overlaps with tests 5/6, and I kind of feel fluidity is somehow affected either way as time passes.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2943231897
There wasn't enough data, so excuse me I had to resort to my (now confirmed flawed) assumption. Now that I did more concrete setup tests, the issue doesn't seem to be worsened by the beta update.
Can we have an open source minimal version of gameoverlayrenderer so that we can see what it's supposed to be doing and tinker with it?
It makes little sense to approach this as closed source companies do when so many people from the community are willing to help Valve developers fix the issue.
If the source code was available this would be fixed in an afternoon.
I want to mention that opting into the Steam Beta client on my openSUSE Tumbleweed system (Ryzen 7, NVIDIA 2070, closed drivers) has resolved this issue for me in both BG3 and FO76. I no longer need to use LD_Preload If there is any information I can provide that can be useful let me know.
Im happy to report that after a few extensive tests with the Steam beta version update that this issue was fixed for me.
I had to perform multiple long game sessions to see if I noticed a difference and yes, the Beta update fixed it for me.
I only play warframe and after 30-35 minutes the game starts to lag horribly, when I touch keyboard and move mouse the game lags periodically every 0.5s. I'm on Arch Linux with Hyprland and linux-lts kernel.
I only play warframe and after 30-35 minutes the game starts to lag horribly, when I touch keyboard and move mouse the game lags periodically every 0.5s. I'm on Arch Linux with Hyprland and linux-lts kernel.
The few fixes I found were as follows
Enabling Steam Overlay
Change recording from off to manual
Made sure Proton experimental was enabled for all games in the settings.
The exact steps can be found in the following link.
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2925504126
Others suggested the following. I'm listing these as the issue seems different depending on the system hardware and software.
Disabling GPU accelerated rendering in web views
Adding commands
LD_PRELOAD=" "
LD_PRELOAD= %command%
Others mention it maybe a dpi setting in the mouse causing these issues. If it only happens when you move your mouse. Try turning down or up the dpi settings to test it.
I'm sorry if I don't reference your link and you were the first to suggest these steps. It isn't hate or anything like that. I'm just lazy and at work at. May edit it in after I get some sleep.
Furthermore, please list the steps you have taken as it helps condense the issue into a more manageable process. Otherwise you get lengthy replies like this one.
As noted in previous replies. The beta version does fix the issue. However, for those that don't want to use the beta the steps above may help.
Once again thanks for coming to my tedtalk.
-A-Wild-Huck
I only play warframe and after 30-35 minutes the game starts to lag horribly, when I touch keyboard and move mouse the game lags periodically every 0.5s. I'm on Arch Linux with Hyprland and linux-lts kernel.
You did see the messages before yours say that it is fixed in Steam Client Beta right?
I only play warframe and after 30-35 minutes the game starts to lag horribly, when I touch keyboard and move mouse the game lags periodically every 0.5s. I'm on Arch Linux with Hyprland and linux-lts kernel.
You did see the messages before yours say that it is fixed in Steam Client Beta right?
Having to use the beta could lead to other issues, as it's a beta. Also I don't think it loaded those messages for me for some reason. This was mostly for people who would like to run normal steam client as it is more stable. Usually.
Added the fix into the post. Thanks
@A-Wild-Huck I think many people have already explained, this is all you need to do if you are not running the beta:
LD_PRELOAD= %command%
fwiw beta isn't needed anymore since this change was part of the stable client update that shipped yesterday
This is still an issue on the current beta as well as the current stable version. e.g. Returnal, the Soul Reaver remakes, Master Chief Collection, etc. suffer from it.
@A-Wild-Huck Will Huck?
Can confirm that this issue persists with the beta client in Counter-Strike 2 as well as the release branch.
Far Cry 3 also suffers, havent noticed this happening on other games (eg. Deep Rock Galactic, Rocket League are fine)
EDIT: It seems some games have this after a longer period eg. Brawlhalla after 65 minutes
The thing is Im pretty sure its a gamescope issue yet I dont think I see anyone mention that here and some even see success turning that off
Still no solution? LD_Preload doesn't fix it for e.g. space marine 2. After X minutes fps are cut to half. Restart the game, works again.
Still nothing new? LD_PRELOAD is not an option for me because it disables my controller...
With the latest version of steam I'm not getting the spike for Deadlock.
I think this is fixed. The people experiencing issues are probably being hit by another bug.
After the beta update, I was still having this issue. My launch params were
gamemoderun gamescope --mangoapp -w 2560 -h 1440 -r 144 -f -- %command%
Removing --mangoapp solved this for me
Steam overlay ON, recording set to manual but I'm not sure if that matters.
5800x3d, 9070xt, 64gb ram, Arch linux 6.15.6-arch1-1 mesa 1.25.1.6-1 kde plasma 6.4.3 (wayland)
Steam overlay ON, recording set to manual but I'm not sure if that matters.
This shows it's a different issue.
Most people on this thread have said the problem was with Steam overlay off.
gamemoderun gamescope --mangoapp -w 2560 -h 1440 -r 144 -f -- %command%Removing
--mangoappsolved this for meSteam overlay ON, recording set to manual but I'm not sure if that matters. 5800x3d, 9070xt, 64gb ram, Arch linux 6.15.6-arch1-1 mesa 1.25.1.6-1 kde plasma 6.4.3 (wayland)
I have no issues recently (overlay off, no LD_PRELOAD workaround) until I use gamescope (with --mangoapp) in a specific game, and it's fixed by adding LD_PRELOAD="".
There's probably something wrong with how gamescope interacts with the overlay and mangoapp simultaneously? Maybe try playing the game without gamescope and see if it makes a difference.
Maybe try playing the game without gamescope and see if it makes a difference.
I do not get any issues at all without gamescope enabled (with or without the steam overlay) but it does REALLY help FPS for me so I would love to keep it enabled
Maybe try playing the game without gamescope and see if it makes a difference.
I do not get any issues at all without gamescope enabled (with or without the steam overlay) but it does REALLY help FPS for me so I would love to keep it enabled
gamescope doesn't even work for me. I wonder if all these issues are related.
Closing comment from me.
After some more extended tests, the stuttering issue was completed fixed for me.
Maybe try playing the game without gamescope and see if it makes a difference.
I do not get any issues at all without gamescope enabled (with or without the steam overlay) but it does REALLY help FPS for me so I would love to keep it enabled
I personally use Hyprland which is a tiling window manager where most games wont like that so gamescope is the solution, but yeah I am pretty sure the issue is related to gamescope as I remember turning it off and not experiencing this lag bomb
The issue still happens for me on the Beta client (from nixpkgs stable), but I have the overlay ON and recording on MANUAL
Currently on Hyprland, so gamescope is pretty much necessary, LD_PRELOAD="" fixes it but then I can't use my Sony controller.
Launch params are --output-height 1080 --output-width 1920 --nested-refresh 144 --fullscreen --adaptive-sync" --expose-wayland
fwiw, there is a gamescope issue tracking the stutter separately from this steam-for-linux issue, might be better to leave gamescope-related comments there: https://github.com/ValveSoftware/gamescope/issues/697
I still have this issue in Kubuntu 25.04 with the fully updated steam client from the .deb package.
Using LD_PRELOAD="" as a startup command fixes the micro lag spikes in some games.
GPU: RX 7600
CPU: Ryzen 7 5700X
Kernel: 6.14 official from Ubuntu.
I still have this issue in Kubuntu 25.04 with the fully updated steam client from the .deb package.
Issue with mouse movement should be "solved" with the fix - not only sometimes.
My guess is, that your system has to little power or the game is just not running smooth.
the micro lag spikes
This issue is about the constant (no spikes here) stutter when moving mouse after playing for a certain amount of time, which AFAIK is fixed. I think people are hijacking this with different issues.
Can everyone just re-test this without any launch options?
which AFAIK is fixed
When has this supposedly been fixed? This still occurs with ValveSoftware/gamescope@6bda0ee (later commits seem unrelated and aren't even part of any release yet) and Steam build 1757650573 from September 12th.
When has this supposedly been fixed? This still occurs with ValveSoftware/gamescope@6bda0ee (later commits seem unrelated and aren't even part of any release yet) and Steam build 1757650573 from September 12th.
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-3246770294
@Revival8697 I'm not sure what you're trying to tell me.
Edit: Mouse related or not (I simply haven't tested without mouse), both issues only seem to affect Steam games, and are probably caused by libraries injected by the Steam client.
I'm not talking about "micro lag spikes" either, but permanent performance drops after 25-40 minutes of playing. So do you really think this isn't the correct issue?
@Revival8697 I'm not sure what you're trying to tell me.
Edit: Mouse related or not (I simply haven't tested without mouse), both issues only seem to affect Steam games, and are probably caused by libraries injected by the Steam client.
I'm not talking about "micro lag spikes" either, but permanent performance drops after 25-40 minutes of playing. So do you really think this isn't the correct issue?
Hello, I tested with and without startup commands all my games run smothly on both but after 20/30 mins I get some micro stutter/spikes for a second if I not use LD_PRELOAD
The LD_PRELOAD thing mitigates this for me.
Not sure if this is a texture loading issue but the command above solves these spikes.
Did we ever get confirmation the fix was actually pushed to live builds? I'm no longer seeing the exact symptoms but launching native games through Steam still incurs a significant performance penalty over launching directly.
At this point I haven't launched Steam or bought anything in nearly a year and I can't see that changing.
This happens to me still on Steam Beta, LD_PRELOAD="" resolves the issue.
Steam Beta Branch: Steam Beta Update
Steam Version: 1759533550
Steam Client Build Date: Fri, Oct 3 18:36 UTC -08:00
Steam Web Build Date: Fri, Oct 3 19:11 UTC -08:00
Steam API Version: SteamClient023
A year without a proper fix is really disappointing for this one. LD_PRELOAD="" breaks some features and isn't exactly a universal solution for me. Some games also just crash or can't launch with it at for me, Warband for one - that's likely a compound funky issue to do with my mods but it's one more point of failure I'd rather not have.
Just to clarify a bit:
The fix was about stutters caused by keyboard and mouse events after a certain period of time, which is fixed a long time ago. (I am one of the people reporting the bug back then, and have been monitoring the progress.)
To be clear, the bug was about "stutters when one actively uses keyboard/mouse but not otherwise." i.e. if you take your hands off your keyboard/mouse and the stutter continues, it's another problem not related to the fix.
It's also important that you update your system packages; some issues actually originate from the interactions among Proton and the OS. For example I used to be able to open multiple fullscreen games with Proton 9.0 just fine, but now they fight for the screen display and fight for keyboard mouse control with the exact Proton 9.0, a new bug that only happens with Proton while Proton 9.0 wasn't changed at all.
With that said, there are some other framerate issues that can happen possibly due to refresh rate or V-syncing under various conditions. I saw some of them and when the stutters happen, it stutters regardless of player input.
This was the issue that I’m still seeing. After 20 minutes or so the game stutters with mouse/keyboard input, the game runs fine if you don’t touch the controls.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-3460254721
Just to clarify a bit: The fix was about stutters caused by keyboard and mouse events after a certain period of time, which is fixed a long time ago. (I am one of the people reporting the bug back then, and have been monitoring the progress.)
To be clear, the bug was about "stutters when one actively uses keyboard/mouse but not otherwise." i.e. if you take your hands off your keyboard/mouse and the stutter continues, it's another problem not related to the fix.
Yes, this is what the bug is about and it has only been fixed for Vulkan/DXVK games (unconfirmed by the developers if only for vulkan games, but probably an accurate assumption, judging by the developers' response to the issue and old Steam changelog regarding it).
My test case illustrated here still holds true to date on the latest Steam beta using Arch Linux and Proton Experimental (no gamescope). The more active the keyboard and mouse input is, the faster it takes for the issue to manifest (can practically manifest in just ~25 minutes):
(4) GoP2PE, no launch options, Proton Experimental. Lag spikes after ~44 minutes only with mouse/keyboard input, mouse input alone creates much more significant spikes (but keyboard-induced spikes can be noticed/tracked). Important clarification: Requires active overall input to experience. Conflicts with test 9 (Proton/Steam possible factors to blame unless the beta update didn't intend to fix the issue here in test 4).
To summarize: Games not utilizing vulkan (supposedly games not utilizing vulkan) will still exhibit the same bug the issue is about. Developers are still silent on why the fix only applies to vulkan games. ¯\_(ツ)_/¯
I'm a little confused. Is this issue not about the strange lag spikes that happen in games after playing for about 30+ minutes?
It still seems to happen to me regardless of what Distro I'm on. Restarting the game makes it go away, but that's less than ideal. I'm on the beta client, and I use gamescope to grab my mouse if it matters
Yep, still happening to me too!
I believe I have a fix for at least one of the issues people are describing in this thread.
When the Steam overlay is open, every new mouse event will get added to a doubly-linked list, but will never get removed. These events are added even if you are tabbed out of the game.
After adding a bunch of events to this list and then closing the overlay, every new mouse event will iterate over this huge linked list and take up an entire core if the list is big enough. In some games this iteration will be in the game main loop which causes huge FPS drops, in other games it'll be in the explorer.exe process, which will still show 100% CPU usage but you might not notice anything because it's not in the main loop.
Repro steps:
- Run any dxvk/vkd3d game with Proton 10.0 (I used Yu-Gi-Oh! Master Duel, a 400mb free game)
- Open the Steam overlay
- Open htop and note the RES memory usage of the explorer.exe process (or the game process, depending on the game used)
- Move your mouse quickly for about 20 seconds
- The memory usage should have increased by a few MB
- Close the overlay and move the mouse a bit, CPU usage of explorer.exe (or the game process) should now be higher than normal while moving the mouse.
If you have a low polling rate mouse such as 125hz you might have to move the mouse a lot more.
This patch fixes it: https://github.com/yepokay/wine/commit/9558034bab9f4872573e7f7ef2f112e90473bd26
Would be nice if some of you could test to see if this fixes it. If there's multiple causes for these timebomb issues then we can at least try to differentiate between them.
Hello,
I pulled the latest bleeding-edge and installed it to see if it resolved things for me, sadly it did not, but I do think it helped performance in the overlay though!
When the Steam overlay is open, every new mouse event will get added to a doubly-linked list, but will never get removed. These events are added even if you are tabbed out of the game. After adding a bunch of events to this list and then closing the overlay, every new mouse event will iterate over this huge linked list and take up an entire core if the list is big enough. In some games this iteration will be in the game main loop which causes huge FPS drops, in other games it'll be in the explorer.exe process, which will still show 100% CPU usage but you might not notice anything because it's not in the main loop.
I can confirm it does indeed fix the explorer.exe spiking in CPU usage while in game, and that it's memory usage doesn't seem to balloon anymore, but for me this isn't the only issue causing frame-time spikes after 25-45 minutes as I still get them. Testing using Dishornered but this happens in multiple games for me, if testing with something else would be helpful.
Thank you for your efforts though @yepokay !
It's a shame it's still a major issue on an operating system Valve is promoting. I've tried to disable and enable Steam overlay, using gamescope, turning on and off game recording (everything I've found on the Internet, basically). The only solution is still the (in)famous:
LD_PRELOAD="" %command%
But some games are basically unplayable, as the Steam overlay is gone.
It has been almost a year after "We believe we have a fix for this issue"...
@AnonymousX86 that is a different issue. As many of us have stated, the original issue is gone. Your issue must be a different one. Have you tried running on Xorg?
LD_PRELOAD="" feels like a bit of a nuke to the issue but this issue if its closed, well its says open at the top and I like the anonymous user above me have this issue, and for me the LD_PRELOAD seems to mitigate it to a large extent but disables a lot of Steam features so it's not a great fix.
Same problem but it only occurs in counter-strike. LD_PRELOAD="" fixes the problem but sometimes the overlay (especially in counter strike) is needed. Not really a solution.
@AnonymousX86 that is a different issue. As many of us have stated, the original issue is gone. Your issue must be a different one. Have you trued running on Xorg?
You are stating something so confidently wrong that its almost adorable.
The core issue of this thread is not fixed.
I did multiple game tests today ( letting games in my steam lib run for over an hour ) and the issue is reproducible.
This is with Tumbleweed KDE and CachyOS/GE-Proton.
You are stating something so confidently wrong that its almost adorable.
It is 100% a fact that this issue happened 1) when the overlay was disabled, and 2) it happened for everyone. Unlike you, I've actually read the entire thread.
I did multiple game tests today ( letting games in my steam lib run for over an hour ) and the issue is reproducible.
Yes, so you have another issue. So? Your issue 1) happens with our without overlay disabled, and 2) only happens for some people. It is a different issue.
That's not how bug report systems work. Every bug report (or issue) is for a specific issue, this instance should not be used for every lagging issue in the game. The specific issue is fixed, this should be closed. Another issue should be opened for the different issue only some people are facing. In that new issue people should mention all the relevant information so developers can find some potential common patterns, my guess is you guys are running wayland.
Your issue has absolutely nothing to do with my issue.
And once again: have you tried on Xorg?
Every bug report (or issue) is for a specific issue, this instance should not be used for every lagging issue in the game.
I'd argue the original bug report is unspecific enough for it to describe multiple issues, related or not. I agree this is problematic, and ideally the original reporter should've included more details.
@TerohsLab was the first person to comment on this thread more than a year ago, so how can you be so confident that you're not the one having another issue? Some people said it's mouse input related, some only have it with gamescope, for some disabling the overlay helped and for others it didn't.
Again, even if these aren't just different appearances of the same underlying bug, the original report is far too vague to say anyone commenting here is in the wrong.
Addendum: The original bug report only mentioned lag spikes occurring 25 to 40 minutes into the game, and it was determined that this is related to libraries loaded by Steam via LD_PRELOAD. I think everyone commenting here agrees on that.
I'd argue the original bug report is unspecific enough for it to describe multiple issues, related or not.
The wording is not specific, but the first thing the report does is mention another thread: doitsujin/dxvk#4436. In that thread it's stated that LD_PRELOAD= fixes the problem and that the only library being preloaded is gameoverlayrenderer.so. So clearly the problem was with the overlay.
Some people said it's mouse input related, some only have it with gamescope, for some disabling the overlay helped and for others it didn't.
No, the original problem happened without gamescope. The people that have problems with gamescope are experiencing a different issue.
And no, you are having it the other way around: disabling the overlay is what caused the problem. 100% of people who disabled the overlay had the problem. That problem was fixed, and it's clear that it was fixed because at some point running with Steam Beta worked, and running released Steam did not.
That's why it's not good to mix multiple issues into one ticket. It only confuses everyone.
So clearly the problem was with the overlay.
That's what we all can agree on, and is also suggested by the label this issue got. But disabling the overlay (or game recording or Steam input) in the settings is not the same as unloading the library.
The people that have problems with gamescope are experiencing a different issue.
You said yourself that there might be an issue related to Wayland. Since Gamescope is itself a Wayland micro-compositor and now functions as a native Wayland client on Wayland systems, this makes a difference compared to running a game directly under Xorg or via Xwayland.
disabling the overlay is what caused the problem
You claim that, but it was never confirmed by the original reporter.
That's why it's not good to mix multiple issues into one ticket. It only confuses everyone.
I agree with you on that, but by now it's too late to determine which issue this specific ticket should be about. So please stop telling people they have a “different issue” when no one knows exactly what the original issue was in the first place. The original report only mentions some symptoms, and these seem to be identical for multiple issues, caused by the same bug or not.
But disabling the overlay (or game recording or Steam input) in the settings is not the same as unloading the library.
No, but both enabling the overlay and using LD_PRELOAD= fixed the problem, as attested by many people in both threads.
Since Gamescope is itself a Wayland micro-compositor and now functions as a native Wayland client on Wayland systems, this makes a difference compared to running a game directly under Xorg or via Xwayland.
And it would be very easy for the people experiencing the other issue to test that, but since you guys are too lazy to do the minimum amount of debugging required to solve the issue, I'll have to do it for you.
That's another indication that this is a different issue that affects only a small amount of people, because the original issue affected a ton of people and we did the job of trying many different things in order to narrow down the problem. The small amount of people that are experiencing a different issue are not doing that, just saying "me too".
You claim that, but it was never confirmed by the original reporter.
It was confirmed in the thread that the original reported referred to.
But it's easy to verify: @darix are you still having the issue?
I agree with you on that, but by now it's too late to determine which issue this specific ticket should be about.
It's not up to you. The developers own the issue system, and they get to decide what this issue ticket is about.
I'm sorry, I'm a little confused, I thought the crux of this bug report was that some interaction between the Steam overlay and gamescope was causing frame-spikes after 25-45 minutes of game play in certain games and that using LD_PRELOAD="" or disabling the Steam Overlay was a working but unacceptable workaround?
And it would be very easy for the people experiencing the other issue to test that, but since you guys are too lazy to do the minimum amount of debugging required to solve the issue, I'll have to do it for you.
I'm not seeing anyone requesting debugging information in recent posts, could you reference which post this was requesting information? I'm happy to do the testing, spent most of a weekend tearing gamescope apart trying to figure out this bug.
It's not up to you. The developers own the issue system, and they get to decide what this issue ticket is about.
Do you think this bug report should be split, or a new bug report created? Because the issue still exists, and is easy to replicate.
Do you think this bug report should be split, or a new bug report created?
https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-3246770294
It's a problem with the libraries that steam-overlay relies on or the overlay itself the low framerates are directly tied to mouse movement.
It's essentially unrelated to gamescope as far as im aware.
I thought the crux of this bug report was that some interaction between the Steam overlay and gamescope was causing frame-spikes after 25-45 minutes of game play in certain games and that using LD_PRELOAD="" or disabling the Steam Overlay was a working but unacceptable workaround?
No, you are wrong, this bug was never about gamescope and it's clear what fixed it: ValveSoftware/wine@6f89fa8. People experienced the bug with or without gamescope, LD_PRELOAD= was a workaround, but so was enabling the overlay (not disabling it).
I'm not seeing anyone requesting debugging information in recent posts
Because the issue is already fixed. No more debugging necessary.
Do you think this bug report should be split, or a new bug report created? Because the issue still exists, and is easy to replicate.
There's already multiple issues about gamescope: ValveSoftware/gamescope#163, ValveSoftware/gamescope#697, ValveSoftware/gamescope#315.
Here are some comments:
When started without gamescope both games run fine next to each other for >3h (as is the case when just running one game).
But CONSISTENTLY after about 25-30 minutes, it stutters, and it never goes away. This only happens when I'm using gamescope. If I don't use it, I can play multiple hours without a hitch.
Your issue is clearly one of those, and they have done way more debugging in those reports.
I spent several hours trying to reproduce the problem and it's clear it only happens when the --mangoapp argument is used. The steam overlay does not matter. This is consistent with what people are reporting in those other bug reports.
If someone sees a problem only with steam overlay disabled, then it's this bug. If someone sees a problem only with gamescope, then it's ValveSoftware/gamescope#163, not this bug.
Downvote me all you want, these are verifiable facts. You are just creating noise and not helping.
If someone sees a problem only with steam overlay disabled, then it's this bug.
Sorry to break it to your AI, but the issue started with people having this issue regardless if the steam overlay was disabled or enabled after they pushed the steam recording feature.
After a year or so there was movement in the beta branch ( was that ever pushed to prod ? ) that fixed the issue for some people, but not for everyone.
I can confirm this is still a issue ( with overlay disabled ). the LD_PRELOAD thing is still required to avoid the lag bomb even after many MANY new nvidia drivers, KDE versions, wayland and millions of proton updates.
The issue is still steam and thats what we are talking about in this issue.
Sorry to break it to your AI, but the issue started with people having this issue regardless if the steam overlay was disabled or enabled
Wrong.
After a year or so there was movement in the beta branch ( was that ever pushed to prod ? ) that fixed the issue for some people,
Wrong. It fixed the issue for everyone.
I can confirm this is still a issue ( with overlay disabled ).
No. You are having a different issue with gamescope that is already tracked by multiple bug reports.
The issue is still steam and thats what we are talking about in this issue.
Wrong. The issue is gamescope.
By the way, it only happens in wayland, not Xorg, and only with the wayland backend: --backend sdl works fine.
Sorry to break it to your AI, but the issue started with people having this issue regardless if the steam overlay was disabled or enabled after they pushed the steam recording feature.
While I kind of agree that this bug as described in the top comment is ambiguous and it's really hard to say what was the "original issue", I don't you can be sure what you said is true. The issue @felipec and I were having, which started at about the time they pushed the recording feature, was fixed by enabling the overlay even if it's not intuitive. I did have that exact issue, which was stutters amplified by mouse movement after X mins while playing a game with the overlay disabled. Enabling the overlay was what fixed it for me at the time (LD_PRELOAD= also worked but that was not the fix I used). That was fixed by Valve about 6 months ago and now I'm back to playing with the overlay disabled without issues.
If you want a detailed analysis on why that was the case, this comment by @d3nd3 has the reasoning: https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200 . There's also a lot more investigation and history if you're up to reading this whole thread.
I do personally think that this bug has accumulated a lot of people with multiple similar but kind of different symptoms and causes and that it would be helpful to have separate bugs for each of them. If you are using gamescope, I would take a deep look at https://github.com/ValveSoftware/gamescope/issues/163 and provide more info or try playing without gamescope to confirm. If your issue is with another setup, I would open another issue and link it here, so it's easier to get more data on a single bug.
I'm saying that because I think it would be easier for everyone as this bug has a lot of history about the issue that only happened with the overlay disabled and are unrelated to the issues people still have, as that's fixed.
I do personally think that this bug has accumulated a lot of people with multiple similar but kind of different symptoms and causes and that it would be helpful to have separate bugs for each of them.
you nailed the issue here. the original bug was just the one issue. and if you see the original bug it linked a very detailed analysis. which probably doesnt apply to many other issues people mix in here.
@darix oh hey you're the original reporter! Can you tell us whether you still have the issue or if it has been fixed for you?
Well, the linked DXVK report you're talking about (https://github.com/doitsujin/dxvk/issues/4436) does match all the symptoms related to the "overlay disabled" bug that has been fixed, including details about relation to mouse and keyboard input and the overlay being disabled, which makes me think even more that this report is for the bug that has been fixed.
Just thought I should post a follow-up, it has been a long time since I last posted about this problem.
I confirm that the LD_PRELOAD workaround still works to this day. The lag timebomb still seems to happen (for me) without the workaround.
EDIT: Also wanted to add that I play without mangohud, on wayland, but that doesn't matter in my case as I get the timebomb regardless, also on X11 which is where the issue originally started for me.
Well, the linked DXVK report you're talking about (doitsujin/dxvk#4436) does match all the symptoms related to the "overlay disabled" bug that has been fixed, including details about relation to mouse and keyboard input and the overlay being disabled, which makes me think even more that this report is for the bug that has been fixed.
It was closed as wontfix because it's a steam bug, linking back to this issue: https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2660179909
So, unless there was a stealth change, this is probably still not fixed. Will try to reproduce later, though I'm inclined to believe @TerohsLab and @SheMelody correctly reproduced the issue.
Same here. No mangohud. I’m not trying to use the overlay, but disabling preload disables things like the steam fps counter and can mess with controller mapping in games using it. Without using LD_PRELOAD=“” I am almost guaranteed to say at some point at about 45 to 60 mins to a friend playing ARC Raiders… “Dude, cover me. Screen froze again. It’ll be back just don’t let me die for like 45 seconds.” But with LD_PRELOAD that just doesn’t happen.
unless there was a stealth change
@TLATER it wasn't stealth, the issue I'm talking about was fixed in "Steam Client Update - June 30th".
Fixed periodic gameplay lag and freezing in games using Vulkan rendering when running with Steam Overlay disabled.
That fix was also commented about by the assignee of this issue on this exact issue, here and here
That said, @SheMelody is the original poster of the DXVK issue (which originated this one) and can still reproduce it, so I think it's fair to say I was wrong and that this bug is NOT about the one the one that's fixed, to help settle that side discussion and so that the discussion can start focusing on the bugs that still happen. I do wonder if the symptoms are all still the same, as she may have had both bugs at the same time (as she had the overlay disabled) or if the symptoms are just similar because they are related to the same mechanism (like the same buffer getting full).
I’m not trying to use the overlay, but disabling preload disables things like the steam fps counter and can mess with controller mapping in games using it.
This snippet has been working for me, it keeps the overlay functional while avoiding the library override for gamescope:
LD_PRELOAD= gamescope -- env LD_PRELOAD="$LD_PRELOAD" %command%
The fact that this works makes me think that we'll just have to wait for the next ubuntu LTS or such.
Weird, given valve target Arch now, but you know what they say about right hand and left hand at big firms.
I am almost guaranteed to say at some point at about 45 to 60 mins to a friend playing ARC Raiders… “Dude, cover me. Screen froze again. It’ll be back just don’t let me die for like 45 seconds.”
Hm, that's interesting, in fact about a month or 2 ago I started having a similar issue on Overwatch where the game would freeze after playing the game for some time, but interestingly almost always at the exact end of the match (like last second of overtime), I would quit and open and it would show as abandoned instead of a win / lose. I never thought about waiting more than 45 seconds so not sure I'd be back. I assumed it was due to some shader at the end of the game, but now if it's actually related to this issue I wonder if it's actually a coincidence due to having a lot mouse movement at that point.
At some other point in the past I also had another freezing (not stuttering) time-bomb but I think that was way before than when I started having the stutter issue, possibly even on Lutris and not Steam.
I'm on Wayland and what fixed the last freeze I was having was switching from Proton-GE to Proton 10. Both Proton-GE and Proton Experimental had the same issue.
Edit: the freeze I have is back, and it's probably completely unrelated to this as it happens even with LD_PRELOAD="" on launch options. The freeze I have is related to NVIDIA's driver, from logs it's the one known as "Xid 109 CTX SWITCH TIMEOUT".
I never used gamescope for anything, but i am using Mangohud with
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%
I can see that the issue can be misunderstood, this reminds me of the Borderlands 4 crash issues: some were related to the game itself yet some were caused by faulty RAM or faulty CPU. Different causes, same (or, well, similar) outcome.
This is very common, it doesn't surprise me and it isn't anybody's fault.
To add some actual useful data to understand the problem, here's a breakdown of when the issue triggers (without using the LD_PRELOAD workaround), everything under the same proton package and under the same proton compatdata:
- Launch a game from Steam that uses DXVK: lag bomb happens.
- Launch a game from Steam that uses VKD3D: lag bomb happens.
- Launch a game from Steam that uses Vulkan (native): lag bomb doesn't happen.
- Launch a game from Steam that uses OpenGL (native): lag bomb doesn't happen.
- Launch a game without Steam with all the mentioned APIs/wrappers (including DXVK and VKD3D): lag bomb doesn't happen.
And this is what the lag timebomb looks like once it triggers (starts at 0:32):
Once the lag timebomb triggers, every given mouse and keyboard input causes a massive lag spike as you can also see on the mangohud graph.
Here's a different video showing the same problem without mangohud:
@SheMelody I confirm that the LD_PRELOAD workaround still works to this day. The lag timebomb still seems to happen (for me) without the workaround.
Yeah but you are using gamescope, aren't you?
@BenStein1 Without using LD_PRELOAD=“” I am almost guaranteed to say at some point at about 45 to 60 mins to a friend playing ARC Raiders…
You are using gamescope, aren't you?
@TLATER This snippet has been working for me, it keeps the overlay functional while avoiding the library override for gamescope:
That's an issue with gamescope. How is this not your issue? ValveSoftware/gamescope#163
@SheMelody To add some actual useful data to understand the problem, here's a breakdown of when the issue triggers (without using the LD_PRELOAD workaround), everything under the same proton package and under the same proton compatdata:
That information is not useful unless you explain if you are using gamescope or not, and with which flags.
That looks completely different to the issue I was having.
It's a different issue. Why do people insist on assigning this issue to steam, when it only happens when using gamescope?
@felipec No, I'm not using Gamescope.
@felipec No, I'm not using Gamescope.
Then you are talking about a completely different issue that no one seems to be talking about here. Did you have the steam overlay enabled? Are you using steam input?
So far it looks people are talking about three different issues here.
@felipec No, I'm not using Gamescope.
Then you are talking about a completely different issue that no one seems to be talking about here. Did you have the steam overlay enabled? Are you using steam input?
So far it looks people are talking about three different issues here.
I'm not talking about a completely different issue, I'm literally the person who posted the original issue in DXVK...
I'm not talking about a completely different issue, I'm literally the person who posted the original issue in DXVK...
Then go comment on that bug. This bug was reported by @darix.
I'm not talking about a completely different issue, I'm literally the person who posted the original issue in DXVK...
Then go comment on that bug. This bug was reported by @darix.
This issue is literally a whole reference to the issue I've previously reported in DXVK, and it is enough to really just read OP's to see that. I genuinely have no idea what you're on about. This issue was indeed opened by @darix but it clearly references and links to the issue I have previously reported. There's no discussion in that.
Moreover, the issue in DXVK is closed, because it isn't a DXVK issue, NOT because the issue doesn't exist. You're telling me to go comment there but that issue is clearly closed.
This issue is literally a whole reference to the issue I've previously reported in DXVK, and it is enough to really just read OP's to see that.
Yeah, but you are not the only person who commented on that thread. Many people said they were not able to reproduce your issue and it has the tag "can't reproduce". You said "this can be easily reproduced on any machine", so clearly the bug reported by @darix is not the same as your bug, because that truly was reproducible on any machine by simply disabling the steam overlay.
Moreover, the issue in DXVK is closed, because it isn't a DXVK issue, NOT because the issue doesn't exist.
This was not a dxvk issue, your issue might be.
Either way, if you don't provide debugging information, your issue won't be fixed. It's as simple as that.
This issue is already fixed, as many people can attest.
@felipec I never use the Steam Overlay, it's always disabled no matter what. Moreover, the issue can indeed be reproduced on any machine pretty easily and I stand by what I said. In all honesty, from a personal standpoint, if you don't even want to help and/or try and reproduce it just unsub from the issue and let other people handle it, it's useless to bloat the discussion on the issue with semantic loops.
I will gladly respond and provide useless insight/info on the problem, but from this point in time I will refrain from fueling useless arguments that don't help with resolving the problem.
(not to mention that everything you're bringing up was already discussed in previous comments)
Moreover, the issue can indeed be reproduced on any machine pretty easily and I stand by what I said.
So everyone who said they didn't manage to reproduce are lying?
I can't reproduce your issue. Am I lying?
if you don't even want to help and/or try and reproduce it just unsub from the issue and let other people handle it
As I already explained, I spent several hours trying to reproduce the issue, and I did manage to reproduce the gamescope issue.
What are you even talking about?
I will gladly respond and provide useless insight/info on the problem
Then why aren't you responding? I asked you:
Did you have the steam overlay enabled? Are you using steam input?
If you don't explain your setup, people cannot reproduce your issue, and your issue won't be solved.
I'll reiterate what was already stated multiple times in years.
Steam Input ON or OFF, Steam Overlay OFF.
Also a TL;DR, there were some hints that the problem itself lied in a library that Steam loads when launching the game (that's why LD_PRELOAD "workarounds" it). More TL;DR a person debugged it somewhere and there was an issue with frame updating.
@felipec give it a rest, this is a proprietary project, without valve chiming in you cannot feasibly distinguish between bugs except by symptom.
For the record, my snippet comes from the same dxvk issue @SheMelody opened - which again, is now closed as invalid and links back to this issue.
But I digress, it's neither your nor our job to do issue triage here, we're literally paying valve to do that.
Just to add more context for those who are relatively new to this problem, and for the sake of saving you some time, this problem dates way way back, even before I opened my issue in DXVK.
You can find this problem everywhere scattered around the whole internet. Search LD_PRELOAD stutter in Google or also csgo stutter LD_PRELOAD.
Play with mouse and keyboard (remember, the issue doesn't happen if you play with a gamepad) and match these for like 25-40 minutes.
@SheMelody I'll reiterate what was already stated multiple times in years.
What was stated in years past is not necessarily relevant because the problem is already fixed.
Steam Input ON or OFF, Steam Overlay OFF.
I spent 10 hours trying to reproduce your issue without gamescope, steam overlay off, steam input off.
I tried with dxvk, vkd3d, proton-ge, proton 10, wayland, Xorg, with mangohud and without mangohud: unable to reproduce.
It's no wonder not a single person has managed to reproduce your issue.
You can find this problem everywhere scattered around the whole internet. Search LD_PRELOAD stutter in Google or also csgo stutter LD_PRELOAD.
No. That's a different issue that is already fixed.
@TLATER give it a rest, this is a proprietary project, without valve chiming in you cannot feasibly distinguish between bugs except by symptom.
Yes I can. I am a developer, I know how to fix bugs.
I can assure you there's 0% chance your bug is ever going to be fixed if the developers cannot reproduce it. If you don't answer questions, the developers are not going to be able to reproduce.
Fortunately for you, your gamescope-specific bug is going to be tracked in the other ticket, where people are answering questions.
@felipec It's not fixed, do you realize that the issue can be reproduced in the exact same way? You say it's a different issue but the repro steps are the same? I'm also a developer and I don't understand your logic at all here.
Edit: Same repro steps, same exact workaround, same exact behavior. Issue is the one referenced in OP's post so it's definitely the issue at hand. I don't really understand how in the world you can even state that this is a different issue.
Fortunately for you, your gamescope-specific bug is going to be tracked in the other ticket, where people are answering questions.
How many times do She has to tell you that there's no gamescope in use?
Stop gaslighting. Touch grass.
Fortunately for you, your gamescope-specific bug is going to be tracked in the other ticket, where people are answering questions.
This issue is NOT related to gamescope, this is a different problem.
Please triple check again OP's post, the referenced problems and answers from users.
@felipec Please do follow and participate in the gamescope-specific problem instead if you wish to fix the gamescope-specific problem. This problem is unrelated to gamescope.
Edit: Moreover, just because you cannot reproduce the issue it doesn't mean that it doesn't exist. Not sure why you can't reproduce it, but I can always reproduce it no matter what, as long as the right conditions are met (I don't want to be redundant, if you need the right conditions to repro it please scroll a bit up).
As already proven this issue can be reproduced by a ton of people, therefore the following statement:
It's no wonder not a single person has managed to reproduce your issue.
is just plain straight incorrect as you can even find users with this problem not only here and other issues but also with a simple Google search as mentioned above.
As @slagiewka suggests, you should really stop gaslighting, even if unintentional. @felipec you said you're a developer, if you wish you can just focus on other issues if you feel more comfortable working with them, you are not forced to debug, reproduce or fix anyone's problems.
This said, I'm really sorry for the wall of text and I hope that from this point in time, discussions here can be about the actual issue at hand instead of semantic loopholes.
There is a very simple way to reproduce this issue :
- Install Overwatch,
- without gamescope,
- Play with mouse & keyboard (really play, you need to move your mouse a lot for issue to happen) for 1h
without LD_PRELOAD="" it should happen between 3 and 6 games.
This looks like an input overflow or some kind of input problem.
@felipec It's not fixed, do you realize that the issue can be reproduced in the exact same way? You say it's a different issue but the repro steps are the same? I'm also a developer and I don't understand your logic at all here.
They are not the same, as I've stated multiple times. Here are the reproduction steps for the multiple issues:
- Disable steam overlay, play for 30 minutes (exact)
- Use gamescope, enable mangoapp, in wayland, play for more than 30 minutes (not exact)
- Completely unknown (your issue)
You provide the link, but you don't actually read what people are saying:
OP: Thank you. I don't use Steam Overlay anyway and have it turned off.
Moderator: Is your steam overlay disabled? There's a known bug with the introduction of game recording in steam that leads to this issue if you've disabled the overlay.
You say the steam overlay doesn't matter, they say it only happens when it's disabled.
Not the same issue.
Edit: Moreover, just because you cannot reproduce the issue it doesn't mean that it doesn't exist.
It is not just me, the main developer of dxvk said this:
Also haven't seen anything like this on my machine even in extended play sessions. As for Unreal Engine titles, I ran Hellblade and Days Gone for ~an hour not too long ago to test some unrelated changes.
Well what I'm saying is that this functionally doesn't make any sense and I can't reproduce it.
If this is an issue that supposedly affects any (UE4) game on any setup then what exactly is it that makes my system the special snowflake that this doesn't happen on?
Why are you pretending I'm the only one unable to reproduce?
As already proven this issue can be reproduced by a ton of people
You have not. Those people were having a different issue that depends on the steam overlay being disabled.
@slagiewka How many times do She has to tell you that there's no gamescope in use?
I wasn't talking to her, I was talking to @TLATER.
She has issue 3, TLATER issue 2.
What part of people are experiencing "multiple issues" is not clear to you?
- Install Overwatch,
I'm not going to install 65 GB just to try to reproduce, especially because even if I do and I'm unable to reproduce, the adamant users here are still not going to accept the issue is not easy to reproduce.
The original report mentions unreal engine games, so I'm installing BioShock Infinite.
I love how ya'll are still engaging with this very obvious rage bait.
From my professional perspective this is a AI training to ragebait in technical topics. They got us all, myself included, good.
Also everyone who got ragebaited has had this LD_PRELOAD issue long enough, that we all know that what this thing is trying to present as "facts" is objectively incorrect information.
I will recite from the old wizard book of "The rules of the internet" ( yes the rule 34 one )
Never feed the trolls. They will drag you down on their level and beat you with experience
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-4245527524
In order to prevent myself from engaging again with the troll I blocked it, and yeah it really got us good. It will serve us as a lesson. At least, due to this incident, we brought up and reiterated fundamental things about the issue, such as how to reproduce it.
And here we go with the 2nd phase : report spamming @kisak-valve
Hello,
I am experiencing an issue that occurs approximately every 10 minutes. Nothing I have tried has resolved it. The problem happens both with the overlay enabled and disabled.
I have tried setting the environment variable LD_PRELOAD="" and running sudo setcap 'CAP_SYS_NICE=eip' $(which gamescope), but neither of these steps helped. The issue occurs in all games.
Unfortunately, at the moment it makes playing games impossible.
@felipec, are you a Valve employee? Why are you ignoring this issue? Your claims that everything is working are incorrect.
Please delegate this ticket to a more competent staff member if you are unable to handle it, and do not interfere with this matter. Thank you.
For me what fixed the problem was not using the steam FPS counter any more. I haven't disabled the overlay entirely and can still summon it with the hot keys.
For the record, I did play more than one hour of BioShock Infinite and experienced no stutter whatsoever. So the claim that this is "easy to reproduce" is simply false. I recorded a video if anyone doubts that.
@Mondrethos this particular issue happened with overlay disabled. If you experienced a problem with it enabled, that's a different issue.
@p2ndemic I'm not a Valve employee. I'm simply trying to narrow down the different issues plenty of people in this ticket want to merge into one. If you experience an issue with the overlay enabled, then you are experiencing a different problem.
I took a break from playing KBM games from Linux for a while due to this issue, but I was able to reproduce just now after 160 minutes in The Thaumaturge. Moving my mouse around basically makes the game freeze. I switched to controller during the same session and was able to move around lag free. So as far as I can tell this is still the same issue tied to KBM input while steam overlay is enabled.
@felipec,
Then a reasonable question arises: if you are not a Valve employee, what is your involvement with this ticket? Please be so kind as not to interfere in this issue - your messages are completely out of place. This ticket was directed to the Valve team, so it should be handled by them. In this case, you are a third party.
- Install Overwatch,
I'm not going to install 65 GB just to try to reproduce, especially because even if I do and I'm unable to reproduce, the adamant users here are still not going to accept the issue is not easy to reproduce.
The original report mentions unreal engine games, so I'm installing BioShock Infinite.
Regarding reproducing the issue - you were given a method to reproduce it. Could you clarify why you ignored it?
Please remove yourself from this conversation; your messages are not appropriate here. Thank you.
I took a break from playing KBM games from Linux for a while due to this issue, but I was able to reproduce just now after 160 minutes in The Thaumaturge. Moving my mouse around basically makes the game freeze. I switched to controller during the same session and was able to move around lag free. So as far as I can tell this is still the same issue tied to KBM input while steam overlay is enabled.
@Kharn501 Were you able to workaround it using the LD_PRELOAD method?
For me what fixed the problem was not using the steam FPS counter any more. I haven't disabled the overlay entirely and can still summon it with the hot keys.
@Mondrethos Interesting, I don't think I've ever tried this. I'll try this later.
I took a break from playing KBM games from Linux for a while due to this issue, but I was able to reproduce just now after 160 minutes in The Thaumaturge. Moving my mouse around basically makes the game freeze. I switched to controller during the same session and was able to move around lag free. So as far as I can tell this is still the same issue tied to KBM input while steam overlay is enabled.
@Kharn501 Were you able to workaround it using the
LD_PRELOADmethod?For me what fixed the problem was not using the steam FPS counter any more. I haven't disabled the overlay entirely and can still summon it with the hot keys.
@Mondrethos Interesting, I don't think I've ever tried this. I'll try this later.
I can try tonight and circle back, but I was coming back to this issue a bit unclear on what the status of the fix is because your original ticket was closed but it that was the exact same cause as this issue right? TLDR is I just wanted to voice that the issue persists as some of the recent replies are claiming it's fixed for them but that may be game dependent at this point (although I'm not an expert). Sorry if I caused any confusion here.
That being said the overlay is such a crucial component for me to either talk to friends or look up stuff that I'd rather just boot into Windows especially as some games don't place nice with alt tabbing out to a browser.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-4364421546
Yes, the issue was closed because it didn't seem to originate from DXVK itself.
@p2ndemic:
@felipec, Then a reasonable question arises: if you are not a Valve employee, what is your involvement with this ticket? Please be so kind as not to interfere in this issue - your messages are completely out of place. This ticket was directed to the Valve team, so it should be handled by them. In this case, you are a third party.
You do not get to speak for the Valve team.
I am a developer, I understand the point of view of Valve developers. You do not.
The first thing Valve developers are going to look for when they have a chance to look at this ticket is a way to reproduce, and there isn't one. That is a fact.
Regarding reproducing the issue - you were given a method to reproduce it.
No, I wasn't. They gave a method that reproduces it on their end, that doesn't mean it's going to reproduce it on my end.
If you were a developer you would understand that.
Could you clarify why you ignored it? Please remove yourself from this conversation; your messages are not appropriate here. Thank you.
If I download the 65 GB required, install Overwatch, play continuously for 1 hour, record a video of me doing so, and I'm unable to reproduce the issue...
Would you and all the people in this thread that have been claiming this issue is "easy to reproduce" accept that in fact, it's NOT easy to reproduce?
No, you won't. So why would I spend so much time and resources doing something pointless?
In all likelihood Valve developers are avoiding this issue because they know if we cannot agree on a way to reproduce this issue, there's 90% chance if they spend 1 hour trying to reproduce this issue, they will not succeed, so why bother?
This issue will just keep gathering dust if you do not provide a way to reproduce this issue. It's that simple.
This issue will just keep gathering dust if you do not provide a way to reproduce this issue.
Anecdotally, this is the single most replied to issue I've ever kept up with. There's a decent number of people that have listed their hardware spec, OS, software flags, versions along with steps to reproduce being repeated ad nauseum.
I'm personally tired of getting notified over bickering. Some of us have been waiting years for a solution, please stop arguing that this ticket needs to get closed. It isn't resolved. Nobody is going to agree with you on the semantics like just give up already.
The first thing Valve developers are going to look
They'll see chunks of usable data and feedback interspersed with 50 comments where you argue. Move on. Please.
P.S. The linked blog explains everything. Nobody here could pierce a skull that thick.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-4439826448
Let's just not engage with them. If they keep inquiring about something that was already provided and/or can be found easily, that means they're not legit. Semantic loops. If you engage, they keep doing it.
Repro steps were provided, videos were provided, conditions were provided.
Legitimate developers are most likely trying to understand why this happens, so let's not pay bad actors any attention.
I've been searching for this issue for some time, and finally came across this thread. I moved from Win11 to CachyOS with KDE on both my laptop and desktop, and they both have this issue. However, my issue doesn't seem to be time based. As soon as I get into some games such as Windrose (UE5) or World of Warships (BigWorld Engine) moving the mouse causes the GPU usage to drop to very low usage (as low as single digit %), and results in low FPS. In the case of Windrose, moving the mouse aggressively can actually cause the game to hang to the point of crashing.
What's interesting is on my laptop, the external mouse causes this issue, but the touchpad does not. And turning the touchpad off has no effect on the lag caused by the external mouse.
For a while my "fix" was to change from CachyOS's in-house Proton to ProtonGE, but that doesn't always work. It fixed Civilization VI, but didn't fix World of Warships.
One last bit of information; I tried to get HDR to work in Tetris Effect and used some commands, such as Proton_Enable_Wayland=1. That command enabled HDR, but caused the mouse lag to appear in the game. It makes me wonder if Wayland has something to do with this. Without the command the game works fine.
My Desktop is AMD Ryzen CPU, AMD Radeon GPU
My Laptop is Intel Core i9 CPU, Nvidia RTX GPU
Both have the same issues in some games when the mouse is moved.
I hope some of this info helps!
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-4429094452
I totally understand you but I must put something here in between.
In my eyes, seemingly it has something to do with how wayland syncs the cursor on the os,
to be more specific "explicit sync",
i do not think its directly related to the new feature, more of we triggered a deeper laying "thing" in wayland, that was even marked as intended behavior,
since you said "i cant reproduce it on my end" let me assume some things: you have either a less polling mouse (eg only 250hz) or a way too good cpu under the hood that manages the mouse and composite spam n updates, smooth enough for you to not notice.
lets test it like this: start stressing your compositor, and while that, use a 1000hz poling mouse.
expected: you will start notice delays in your cursor movement, it will start appear more and more unsmooth, sometimes stuttery, lagging behind, also causing other programs to lag while moving the cursor.
even though your CPU and RAM wasnt used that much.
the reason why its so hard to reproduce for so many devs-
(because i understand you in that thing, you cant really help or reproduce it, which means often its not the feature itself more of the users setup / configuration)
-might be just because its very setup specific and wayland specific.
i would be stumbled if anyone is finally able to point to the actual issue, but since its might be a wayland specific issue (i do not have that on x11, and x11 has asynchronous mouse updates while on wayland you have synchronized updating), meaning the issue is pretty obvious to me.
As mentioned in this Lobster thread it is even intended behaviour
thank you i hope i could give some progressive helping thoughts to get further.
Have a great day.
@x0rp01s0n Originally, I always reproduced this on X11, and that's where the original issue that I have opened originated from, I only started using Wayland quite recently and I can reproduce it there as well.
since you said "i cant reproduce it on my end" let me assume some things: you have either a less polling mouse (eg only 250hz) or a way too good cpu under the hood that manages the mouse and composite spam n updates, smooth enough for you to not notice.
I did try that. My mouse default polling rate is 1000 hz, but I increased it to 8000 hz to see if I could reproduce the issue. I did have some trouble running Deadlock, but that seems to be a completely different new issue regarding dxvk.
lets test it like this: start stressing your compositor, and while that, use a 1000hz poling mouse.
expected: you will start notice delays in your cursor movement, it will start appear more and more unsmooth, sometimes stuttery, lagging behind, also causing other programs to lag while moving the cursor.
even though your CPU and RAM wasnt used that much.
I could try that on an Unreal Engine game running Wayland for 1 hour, but to be honest. What for?
If I don't manage to reproduce it, the original reporter will still not accept that the issue isn't "easy to reproduce".
And all the users here are downvoting me for explaining how development works.
So I don't think their issue is ever going to be fixed. However, this issue — the one most people experienced — is already fixed.
I hadn't experienced this issue for 10 months until I upgraded my setup a month ago—moving from an i5-13500 with an RTX 3070 and DDR4 to a Ryzen 7 9850X3D with an RX 9070 XT and DDR5.
It doesn't happen in every game; for instance, Counter-Strike 2 runs perfectly with no issues at all. However, in games like Gray Zone, Doom (2016), Hitman, Arma Reforger, and Imperivm RTC, it consistently triggers after about 30 minutes to 1 hour of continuous gameplay.
It doesn't happen in every game; for instance, Counter-Strike 2 runs perfectly with no issues at all. However, in games like Gray Zone, Doom (2016), Hitman, Arma Reforger, and Imperivm RTC, it consistently triggers after about 30 minutes to 1 hour of continuous gameplay.
Is it the same issue though? Is it a lag spike or does it completely freeze?
It doesn't happen in every game; for instance, Counter-Strike 2 runs perfectly with no issues at all. However, in games like Gray Zone, Doom (2016), Hitman, Arma Reforger, and Imperivm RTC, it consistently triggers after about 30 minutes to 1 hour of continuous gameplay.
Is it the same issue though? Is it a lag spike or does it completely freeze?
Constant stuttering occurs whenever I move the mouse. It doesn't happen at all if the mouse is completely still. For example, if the game is running at 80 FPS and the frametime spikes hit, it drops to 40 FPS while moving the mouse, but it feels like 20 FPS. The moment I stop moving it, it goes back to 80 FPS.
Using LD_PRELOAD="" fixes the issue, but then I lose the entire overlay, which defeats the purpose for certain games.
Using LD_PRELOAD="" fixes the issue, but then I lose the entire overlay, which defeats the purpose for certain games.
It also seems that steam input doesn't work without the overlay. Even if overlay is disabled using the UI in steam, or using LD_PRELOAD="". Steam Input is critical is some cases, if game don't support controllers natively. This is a case for Monter Hunter Wilds.
I keep returning to using Linux every few months to see if anything has changed but every single time I throw on a new game to try this issue ends up happening to me. This past week I booted up Linux for the first time in a while to install KCD2 and ran into the issue yet again after ~90 minutes of in game (I'm aware disabling overlay is a workaround but not something I consider a true fix).
At this point many people have listed specific games and the time limit to reproduce this issue but there's no update from Valve except to close new threads and repoint them here. I'll admit I'm only a casual git user but why has Valve provided no updates here when this has been open for basically almost 2 years with hundreds of replies stating specific games and time limits that reproduce the issue?
Edit: I did try switching to GE proton 11-1 for the hell of it instead of proton-cachyos and I was able to do 2 hours of Eriksholm The Stolen Dream without the lag issue popping up. That would make it the first time in basically over a year in which I've been able to get past the 60-90 minute mark without the lag issue popping up. I have no clue if proton version even matters at this point but thought it was interesting. I can try to see if I can do like 2 hours of KCD2 tomorrow testing the same method and see if somehow fixes it.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-4949598951
It might actually be some kind of extremely weird problem, devs are probably still trying to solve the puzzle.
For now, LD_PRELOAD="" is the way to go. You can actually preload anything you need in LD_PRELOAD and the lag problem still won't happen, here's a random example from my Black Mesa installation:
DISABLE_OBS_VKCAPTURE=0 OBS_VKCAPTURE=1 GLIBC_TUNABLES=glibc.malloc.hugetlb=2 DISABLE_GAMESCOPE_WSI=0 ENABLE_GAMESCOPE_WSI=1 DISABLE_MANGOHUD=0 MANGOHUD=1 VK_INSTANCE_LAYERS=VK_LAYER_FROG_gamescope_wsi_x86_64:VK_LAYER_MANGOHUD_overlay_x86_64:VK_LAYER_OBS_vkcapture_64 VK_LOADER_LAYERS_ENABLE=VK_LAYER_FROG_gamescope_wsi_x86_64,VK_LAYER_MANGOHUD_overlay_x86_64,VK_LAYER_OBS_vkcapture_64 LD_PRELOAD="/usr/lib/libvulkan.so:/usr/lib/libVkLayer_FROG_gamescope_wsi_x86_64.so:/usr/lib/mangohud/libMangoHud.so:/usr/lib/libVkLayer_obs_vkcapture.so" gamescope -W 1920 -H 1080 -w 3840 -h 2160 -r 237 --borderless --immediate-flips --mangoapp -- %COMMAND%
What this huge mess does is still load what I need while keeping the LD_PRELOAD="" workaround in place, essentially only loading what I explicitily declare.
There are some caveats and things that you should keep in mind in this example here, first off I use forced WOW64 so you actually need x64 linux layers, not 32-bit. Then in regards of the double VK_INSTANCE_LAYERS plus VK_LOADER_LAYERS_ENABLE which may sound redundant but it isn't since the vulkan icd loader often ignores what's declared in the 2nd env variable, therefore I just declare the layers twice to prevent that bug from happening. And I did the --mangoapp + mangohud loading thingy to also workaround another bug that causes mangohud to sometimes not load (specifically when using --mangoapp).
EDIT: If you somehow need the --mangoapp + mangohud load workaround, remember to add no_display to the configuration or you will instantly crash.
It might actually be some kind of extremely weird problem, devs are probably still trying to solve the puzzle.
While it might be a weird problem after all, them having absolutely no communication on this is the true crime @kisak-valve
- We know exactly when it happened : When they introduced the recording feature to the steam overlay. There is 0 discussion here.
- We know its 100000% reproducable
- We know they have said, in this thread, that they know its an issue
- Ignore!
- Profit?
Stop white knighting a 20bil profit company for not doing even its BASIC job on a 3 year old issue.
You guys / girls and everything it between and outside need to seriously rewire you brain when it comes to those walls of text command lines.
You can put a user_settings.py in the root folder of each comp tool in ~/.steam/root/compatibilitytools.d/ to set those commands.
There is even a user_settings.sample.py in each of them to learn the structure.
These ENV vars will be applied to any game you launch with this comp tool ever if you have nothing in your command line in steam.
Reminder : these will get overwritten on new versions unless you handle it via a proton manager or symlinks ( in my case ProtonPlus which even handles symlinked user_settings.py now.
My user_settings.py looks like this for both ge-proton and cachyos-proton :
#
# Settings here will take effect for all games run in this Proton version.
#
user_settings = {
# Fix steam overlay timebomb
"LD_PRELOAD": "",
# Enable Mangohud
"VK_LOADER_LAYERS_ENABLE": "VK_LAYER_MANGOHUD_overlay_x86_64",
# Enable WAYLAND
"PROTON_ENABLE_WAYLAND": "1",
"WAYLANDDRV_PRIMARY_MONITOR": "DP-1",
# Upgrade FSR and DLSS
"PROTON_FSR4_UPGRADE": "1",
# "PROTON_FSR4_INDICATOR": "1",
"PROTON_DLSS_UPGRADE": "1",
# "PROTON_DLSS_INDICATOR": "1",
# Disable resizable bar
# https://github.com/HansKristian-Work/vkd3d-proton
# "VKD3D_CONFIG": "no_upload_hvv",
#
# CachyOS-Proton only
#
# Enable permanent local shader caches
"PROTON_LOCAL_SHADER_CACHE": "1",
# Enable async shader compiling
"PROTON_DXVK_LOWLATENCY": "1",
# Disable window decorations
"PROTON_NO_WM_DECORATION": "1",
# Enable nvidia reflex
"PROTON_VKREFLEX": "1",
# Enable experimental HEAP DX12 "fix"
"PROTON_VKD3D_HEAP": "1",
"VKD3D_CONFIG": "descriptor_heap",
#By default, logs are saved to $HOME/steam-<STEAM_GAME_ID>.log, overwriting any previous log with that name.
#Log directory can be overridden with $PROTON_LOG_DIR.
# Enable DXVK's HUD
"DXVK_HUD": "compiler",
#enable logging
# "PROTON_LOG": "1",
#custom Wine debug logging
#"WINEDEBUG": "+timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree",
#DXVK debug logging
# "DXVK_LOG_LEVEL": "info",
#DXVK-NVAPI debug logging
# "DXVK_NVAPI_LOG_LEVEL": "info",
#vkd3d debug logging
# "VKD3D_DEBUG": "warn",
#vkd3d-shader debug logging
# "VKD3D_SHADER_DEBUG": "fixme",
#wine-mono debug logging (Wine's .NET replacement)
# "WINE_MONO_TRACE": "E:System.NotImplementedException",
#"MONO_LOG_LEVEL": "info",
#xalia debug logging
#"XALIA_DEBUG": "1",
#"XALIA_DEBUG_INPUT": "1",
#general purpose media logging
# "GST_DEBUG": "4",
#or, verbose converter logging (may impact playback performance):
# "GST_DEBUG": "4,WINE:7,protonmediaconverter:7",
# "GST_DEBUG_NO_COLOR": "1",
}
@TerohsLab I'm glad that you prefer using user_settings.py and some kind of external manager, but I'm oldschool and I absolutely don't agree, I prefer doing everything manually and setting launch parameters for each game as there are games that require slightly or massively different things. Most stuff is in /etc/environment for me, some additional stuff added to PATH in order to use proton externally via commandline and custom prefixes, and much much more. The only thing I need as a "manager" is winetricks, which can be used on proton if you point it to the pfx directory, to install things such as dsoal, and that's really it. Thanks for the suggestion, though, some users might actually like your approach and start using it.
and setting launch parameters for each game as there are games that require slightly or massively different things.
Launch commands in steam have -1 priority. They will always apply first no matter what you set in anything else.
user_settings.py is a good way to to set the defaults and then use ( for example ) :
PROTON_ENABLE_WAYLAND=0 in the command line for some games to disable wayland for them, because they dont work with it.
@TerohsLab I'll see if this turns out to be helpful in any way for me as an experiment, but the additional symlinks/managers part kinda raises an eyebrow for me, and I have to be sure that certain games will actually override these settings (ie. Unity games breaking with AF, so I need to workaround it, and so on).
Edit: a small suggestion for your script, you should load vulkan layers with both VK_INSTANCE_LAYERS and VK_LOADER_LAYERS_ENABLE. The 2nd environment variable is unreliable and I can always reproduce it, on the first launch it doesn't load all the layers, 2nd launch fixes it.
Edit2: I figured I don't really want 'defaults' for games for a lot of reasons that I'm not going to list (off-topic), for now I won't use that file.
At this point many people have listed specific games and the time limit to reproduce this issue but there's no update from Valve except to close new threads and repoint them here.
That was for a separate issue that was already solved. If your issue is not solved, then not a single person has provided a way to reliably reproduce the problem.
The obstacle in this particular ticket is that the users affected by the secondary problem are not willing to listen.
So whatever problem they are facing will be fixed somewhere else, not through this ticket.
Issue still persists for me. Unreal Engine games are always affected (e.g. First Berserker Khazan - AppId 2680010).
Steam Version 1784145295
Happens after ~50 minutes after starting the game regardless of input activity.
LD_PRELOAD="" fixes it, but breaks gamepad support, which is not ideal.
Originally I used a workaround where I replaced the gameoverlayrenderer.so with a version just before the game recording deployment, but Valve has patched that by forcing an online validation of all dependencies on launch.
Now that this has stopped working, it's become a nuisance for me yet again.
Will gladly test other things and provide additional information if necessary.
@dNifle
Valve has patched that by forcing an online validation of all dependencies on launch
steam -noverifyfiles
from Valve Software Wiki https://developer.valvesoftware.com/wiki/Command_line_options_(Steam)
The secondary issue related to gamescope has been fixed: in ValveSoftware/gamescope@e399345. Just like I said: it was present only while running wayland.
The tertiary issue that few people are experiencing not related to gamescope and/or wayland nor this bug is not reproducible, and given the lack of feedback from developers, it's unlikely anyone is working on it. And if the users experiencing this separate issue don't open a new ticket with instructions on how to reproduce it, it's likely to stay that way.
Downvoting this comment is not going to change that fact.
2 out of 3 separate issues have been fixed, so 2 issue tickets should be marked as closed.
Additional entry path: stale /var/home paths in the Vulkan layer manifests
I hit this bug with the overlay enabled, which doesn't match the usual
"overlay disabled" description. The cause turned out to be a leftover from a
distro migration, and it may explain why some users still see this after the fix.
Setup: CachyOS (previously Bazzite), NVIDIA 610.57.04, Proton, Crimson Desert
and Coral Island. Symptom is the familiar one: after ~40-80 min of active play,
p99 frametime jumps from ~20 ms to 65-85 ms while GPU utilisation drops from ~97%
to 50-70%. Only input triggers it, restarting the game resets it.
What was wrong: all four manifests in ~/.local/share/vulkan/implicit_layer.d/
contained paths prefixed with /var/home/:
"library_path": "/var/home/<user>/.local/share/Steam/ubuntu12_64/steamoverlayvulkanlayer.so"
/var/home is the home layout used by Fedora Silverblue and Bazzite. After moving
to a distro that uses /home, the files came along unchanged and Steam never
rewrites them. steamoverlay_{i386,x86_64}.json and steamfossilize_{i386,x86_64}.json
were all affected.
Consequence: pressure-vessel resolves the manifest to a path that doesn't exist,
so it cannot expose the library inside the container. With VK_LOADER_DEBUG=all the
string steam_overlay never appears in the log at all — the loader only ever sees
five manifests under /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d,
none of which is the overlay. steamoverlayvulkanlayer.so is absent from
/proc/<pid>/maps, even though gameoverlayrenderer.so is loaded and
ENABLE_VK_LAYER_VALVE_steam_overlay_1=1 is set in the environment.
So VulkanSteamOverlayPresent() never runs, the InputEvent SHM is never cleared,
and the buffer fills — the exact mechanism described in #11729, but reached with the
overlay switched on.
Fix:
sed -i 's|/var/home/|/home/|' ~/.local/share/vulkan/implicit_layer.d/*.json
Verification: grep -c steamoverlayvulkanlayer /proc/<pid>/maps returns > 0
afterwards, and Shift+Tab opens the overlay. First run after the fix: 126 minutes of
active play with no timebomb, p99 staying at 19-37 ms throughout. Previous runs
consistently hit it between 38 and 81 minutes.
I hit this bug with the overlay enabled, which doesn't match the usual
"overlay disabled" description.
That's not what the "usual" description in this thread is, your LLM summarized something wrong. People are effectively recommending disabling the overlay (by setting LD_PRELOAD="") because it appears to be involved in this behavior.
For the record, my manifest files point to the right place, and I have never migrated any steam libraries between distros, but this bug remains present in certain games.
It is curious that you see the timebomb disappearing when you add those libraries, though. I'm sure that could help debug the actual issue.
I think, i collected around 88 mangohud across the whole August. The weird thing is, that i did not have this behavior in Bazzite at all, it appeared only after my migration to CachyOS.
I still need to do more testing, if the "timebomb" really disappears. And i need to test more games. Currently only Crimson Desert consistently has this issue.
I think, i collected around 88 mangohud across the whole August. The weird thing is, that i did not have this behavior in Bazzite at all, it appeared only after my migration to CachyOS.
I was going to comment about this after testing this better but I also think it's related to proton-cachyos, I don't think it's happening anymore to me after switching to steam's proton or even proton-ge
I not using CachyOS-Proton in Steam. I stick to Valve's Proton-Experimental "Bleeding Edge".
Ok, and to clarify I am not on CachyOS but I esperienced it only recently and possibly when I tried its proton version. There might be a correlation.
Proton versions
proton experimentalx14 2026-08proton 10.0x1 2026-01proton 9.0x1 2025-10proton 9.0-4x4 2025-06ge-proton9-23x3 2025-06ge-proton9-11x2 2025-03ge-proton9-25x2 2025-03
Launch options
PROTON_ENABLE_WAYLAND=0x1 2026-07DXVK_HUDx2 2026-07DXVK_LOG_LEVELx1 2026-07DXVK_NVAPI_LOG_LEVELx1 2026-07PROTON_DLSS_INDICATORx1 2026-07PROTON_DLSS_UPGRADEx1 2026-07PROTON_DXVK_LOWLATENCYx1 2026-07PROTON_ENABLE_WAYLANDx1 2026-07PROTON_FSR4_INDICATORx1 2026-07PROTON_FSR4_UPGRADEx1 2026-07PROTON_LOCAL_SHADER_CACHEx1 2026-07PROTON_LOGx1 2026-07PROTON_LOG_DIRx1 2026-07PROTON_NO_WM_DECORATIONx1 2026-07PROTON_VKD3D_HEAPx1 2026-07
Launch lines
LD_PRELOAD="$LD_PRELOAD" %command%x1 2026-04LD_PRELOAD="" %command%x9 2026-03gamemoderun gamescope --mangoapp -w 2560 -h 1440 -r 144 -f -- %command%x2 2025-07gamemoderun %command%x1 2025-06SDL_VIDEODRIVER=wayland %command%x1 2025-05LD_PRELOAD="" %command% -novid -console +execx1 2025-03PROTON_USE_WINED3D=1 %command%x1 2025-02LD_PRELOAD="/home/USER/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so" %command%x1 2025-01LD_PRELOAD=" " %command%x2 2024-12LD_PRELOAD="" mangohud %command% -noborder -windowedx1 2024-12
Upstream links
- ValveSoftware/steam-for-linux/issues/11446x42 2026-07
- doitsujin/dxvk/issues/4436x8 2026-05
- ValveSoftware/gamescope/issues/163x3 2026-04
- ValveSoftware/gamescope/issues/697x1 2025-09
- ValveSoftware/SteamOS/issues/1882x1 2025-05
- ValveSoftware/Proton/issues/8313x1 2024-12
A lot of details are already collected in:
https://github.com/doitsujin/dxvk/issues/4436
it could be related for a LD_PRELOAD added for the "record your game" feature?
the workaround while we wait for the fix
please see this comment for all the details https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2466646597