51–60 of 202 posts
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. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...
Why is udev not used in this case?
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.
SDL wants to support hotplugging where you can plug a controller in after you have already started the game.
I would imagine that’s what’s done if you’re running udev but maybe SDL doesn’t do that.
Earlier quoted context omitted.
This is one of the reasons I use Gentoo in my desktops: you can run a "stable" (as in old) system, but pull a more recent version of a library or application if you need it. For example, I remember having problems accessing files that I had stored in my mobile phone. Solution: updating libmtp and libmtp only. I suppose you can't do this in a distro such as Debian without upgrading half the packages. Are there more di…
If you are advanced enough to run Gentoo, you should be able to use Debian and force an install of (or re-compile yourself) a new package of the newer version, working around the fact that the official newer version would otherwise require other new packages.
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.
SDL should probably use inotify() on linux so the kernel can let it know when /dev/input has changed rather than polling it.
It seems like Papers, Please uses a statically linked version of SDL, without udev or inotify support compiled in.
1: https://github.com/libsdl-org/SDL/blob/d0de4c625ad26ef540166...
The issue has been identified before, but seems like it stalled: https://gitlab.freedesktop.org/libinput/libinput/-/issues/50... , https://patchwork.kernel.org/project/linux-input/patch/20201... .
The proposed patch isn’t a comprehensive fix, it admits there are still other sources of relatively high close() latency.
So that got me thinking, there is no way to fix this “bug” because there is no specification on how long close() should take to complete. As far as we are promised in user-land, close() is not an instantaneous operation. close() is a blocking operation! Even worse, it’s an IO operation.
So now I think the bug is in the application. If you want to avoid the latency of close() you should do it asynchronously in another thread. This is similar to the rule that you should not do blocking IO on the main thread in an event-loop based application.
Earlier quoted context omitted.
A lot of games will automatically switch between keyboard and gamepad when a gamepad is connected. Perhaps this is some automatic background function that SDL handles.
Windows uses a similar polling-based approach, with a warning that you shouldn't poll for new gamepads every frame for performance reasons: https://docs.microsoft.com/en-us/windows/win32/xinput/gettin... In general, "notifying the program when a new device has become available" seems to be a surprisingly difficult problem. I've encountered trouble with multiple device types across multiple platforms.
Earlier quoted context omitted.
SDL wants to support hotplugging where you can plug a controller in after you have already started the game.
Operating systems let you know when a device change has happened. You can even cache this where you pool the first time for the initial set of data and then you just check when a device is plugged in to update your knowledge of the state of the world. I would imagine that’s what’s done if you’re running udev but maybe SDL doesn’t do that.
Earlier quoted context omitted.
From one of the printouts in the post, it seems that Papers Please is using a bundled and statically linked SDL. So it would be the game developer that would have to update the version of the SDL library. The binary patching done seems like a good-enough alternative in the meantime. I have the feeling such bundling of dependencies is fairly common when porting games for Linux.
SDL has its own "dynapi" layer, where you can override it with your own copy of SDL even if it was statically linked: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...
Wait, why is `close` in libpthread.so?
As for why close specifically though, that’s a good question. I wonder if it has something to do with special libc treatment of the standard fds or anything like that.