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.

Originally posted by @d3nd3 in [#11446](https://github.com/ValveSoftware/steam-for-linux/issues/11446#issuecomment-2637736200)