The issue has been identified before, but seems like it stalled: <a href="https://gitlab.freedesktop.org/libinput/libinput/-/issues/509" rel="nofollow">https://gitlab.freedesktop.org/libinput/libinput/-/issues/50...</a>, <a href="https://patchwork.kernel.org/project/linux-input/patch/20201227144302.9419-1-kl@kl.wtf/" rel="nofollow">https://patchwork.kernel.org/project/linux-input/patch/20201...</a>.
I really enjoyed the debugging process here, and am glad to have learnt about the -k flag which seems to only be available on systems with strace version 5.5, at least for me.<p>As for the patch (and my love for all things Frida [1]), I think a call to Intercerptor.replace() after locating the symbol with Module.getExportByName() [2] would make for a simpler patch (at the cost of installing Frida). For example:<p><pre><code> const sym = Module.getExportByName("lime.ndll", "SDL_SemWait");
Interceptor.replace(sym, {
onEnter: function() {},
onLeave: function() {}
});
</code></pre>
[1] <a href="https://frida.re/" rel="nofollow">https://frida.re/</a><p>[2] <a href="https://frida.re/docs/javascript-api/#module" rel="nofollow">https://frida.re/docs/javascript-api/#module</a>
From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago.<p><a href="https://github.com/spurious/SDL-mirror/commit/59728f9802c7869a9b47d6176296086dc0d00d45" rel="nofollow">https://github.com/spurious/SDL-mirror/commit/59728f9802c786...</a>
This reminds me of the recent Linus Tech Tips series on gaming on Linux[1]. Their conclusion is that although many games work out of the box (although usually not at launch), Linux is not ready for mainstream gamers. Not many people would have the expertise or the interest to troubleshoot the problem as OP did.<p>[1] <a href="https://www.youtube.com/watch?v=Rlg4K16ujFw" rel="nofollow">https://www.youtube.com/watch?v=Rlg4K16ujFw</a>
strace tip of the day: you don't need lsof, strace can keep track of open fds quite well, just use the -y flag.<p><pre><code> -y
--decode-fds
--decode-fds=path
Print paths associated with file descriptor arguments.
-yy
--decode-fds=all
Print all available information associated with file
descriptors: protocol-specific information associated with
socket file descriptors, block/character device number
associated with device file descriptors, and PIDs
associated with pidfd file descriptors.</code></pre>
Hey, I know this issue! I ran into it in CK3 when it launched. You can also work around it by running chmod go-rx /dev/input/ while playing your game. Whether this is more or less invasive than binary-patching the game is up for debate.
Fun write up. Here’s another example of a binary patch to fix a Linux game issue:<p><a href="https://steamcommunity.com/app/333300/discussions/0/2646360608736518971/?ctp=2#c3050608970471835150" rel="nofollow">https://steamcommunity.com/app/333300/discussions/0/26463606...</a>
Interesting tidbit about Papers, Please: it's written with Haxe (a programming language), on top of OpenFL (an open-source Flash alternative), which uses Lime as its foundational cross-platform library. The nice stack traces you see in the article, such as:<p>openfl::display::Application_obj::__construct<p>are because Haxe actually compiles down to C++! (That's also why it has nice interop with C/C++ libraries like SDL.) Haxe boasts an insane amount of compile targets -- just taking a glance at its Github page, it can compile to Javascript, C#, C++, Java, Lua, PHP, Python, and Flash, plus a couple different Haxe-specific interpreters.<p>Not many game developers use Haxe, so it has a small, tight-knit community. Other well-known games written with Haxe include Dead Cells, Northgard, and Dicey Dungeons.
Why is the engine even checking input devices so often? Shouldn't the input device be registered via settings and then assumed to exist when the game runs? It seems wasteful to check all input devices every few seconds.
Some time ago I've also stumbled upon this issue and found the workaround that I've posted here: <a href="https://www.gog.com/forum/papers_please/terrible_lags_on_linux_with_nvidia_gpu/post3" rel="nofollow">https://www.gog.com/forum/papers_please/terrible_lags_on_lin...</a><p>Thanks for a more proper digging.
This looks very like a problem I encountered some time ago running the closed source 3DO emulator "Phoenix Project", and similarly the open source "FreeDO" project that it was forked from. I narrowed it down (also using strace, IIRC) to these programs repeatedly opening and closing the /dev/input/event* files, and that being weirdly slow. I made a seperate little test program just to open and close those files to confirm it. It was only slow on my main desktop machine; while on my lesser-powered laptop, running a practically identical Arch Linux setup, those file operations were quick and the programs ran fine. None of these programs use SDL. I couldn't/didn't progress any further then, but it's good to find some pointers here for further investigation (ie. the libinput issue).<p>Funnily enough I'm pretty sure I played Papers Please on this machine at length without problems but I think that was probably the Windows version through Wine.
This is interesting. I never noticed these pauses using the native port from GOG on Ubuntu. I'm very sensitive to this kind of thing (low refresh rates on CRT monitors used to drive me crazy when nobody else noticed).<p>Will have to fire up my copy again. A good excuse to play this marvelous game again.
Interesting investigation. I don't remember having this problem when playing the GOG version, but may be I didn't have a lot of input devices?