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.

There’s a reason Plug’n’Play and USB were big deals back then. The concept of plugging in a new peripheral and it just working, without rebooting, was rather revolutionary. Even though the former was more aptly called “Plug’n’Pray” in the early years…

SDL has an event for when a new gamepad is detected or removed: http://wiki.libsdl.org/SDL_ControllerDeviceEvent although I don’t know what it does internally in order to detect this (well, the article describes what it does).

But you can also manually enumerate devices as in the example here: http://wiki.libsdl.org/SDL_GameControllerOpen

SDL should probably use inotify() on linux so the kernel can let it know when /dev/input has changed rather than polling it.

SDL has three methods for detecting input devices [1]: udev, inotify, and, as a fallback, enumerating /dev/input.

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...

I've been wondering.. is it possible to write something to override the statically linked functions? In this case, most (if not all) functions have an SDL_ prefix. Would it be possible to LD_PRELOAD a library that loads a shared version of SDL and goes over all the function pointers to move them point them to a new location? Is there a tool for this?

> I've been wondering.. is it possible to write something to override the statically linked functions?

SDL does have a built-in way to do that trick. A quick web search tells me it's called SDL_DYNAMIC_API.

cool, I never knew! Somehow the game I thought it would add a feature is still lacking it. For some reason rumble on my xbox joystick with Enter the Gungeon never worked. I thought it was because of an old SDL version, because experimentation showed that. But by using the SDL_DYNAMIC_API env and loading my system SDL the game still not added rumble to my joystick. Ohwell.

SDL_DYNAMIC_API is a relatively recent addition (IIRC 2014), so static SDL2 builds from before that won't work this way.

It looks like SDL's public symbols are all global in lime.ndll so LD_PRELOADing SDL should do what you want. Of course it is possible that lime.ndll was built with -fno-semantic-interposition or equivalent in which case the functions might be called directly without going through the dynamic linker or even (partially) inlined.

Well if you know where to fork, you could use Intel Pin and divert the CFG, favorite tool for binary 'patching'.

Edit: though here if it's a problem of file enumeration and access, I'd probably just LD_PRELOAD something to bypass libc file access functions and return the same result than the first time, with no delay.

Static linking means the features of the Linux dynamic loader, like using the environment variable LD_PRELOAD to pre-load a dynamic library, are not going to have any effect.

Actually, I think the truly preferred path is to just monitor for udev events, which SDL supports but is presumably not enabled for Papers, Please for one reason or another.

Exactly. It should enumerate them when the player opens settings. Or at startup.

But even if it wants to do this, why is it doing it on the main thread!? :(

If I start the game without a gamepad attached to the computer, and then attach the gamepad, I'd like to use the gamepad without restarting the game. And one would expect that polling the attached input devices should never take hundreds or thousands of milliseconds, there must be something seriously wrong in the Linux input device stack or maybe in one of the input device drivers.

The input stack is fine, this game disabled the things that would let it work nicely (see upthread discussion of SDL supporting udev and inotify)

Or maybe just poll for new input devices when the game is paused, or before the game starts.

Then you still have problems to handle like accidentally disconnecting/reconnecting the gamepad when somebody stumbles over the cable (for instance the game might want to automatically pause if the gamepad suddenly 'disappears' for any reason). Gamepads should be automatically detected at any time in the game as they are connected or disconnected. That's how it works on game consoles, and PC games shouldn't behave any different in that regard IMHO.

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.

As has been noted in another subthread, SDL can do this but apparently the particular statically linked version shipped with Papers Please is compiled without udev or inotify support and has to fallback to manual checking.

Yes, and even if it checks for new devices, it should only need to check devices it hasn't already checked.

Ah, but are /dev/input entries reusable?

Let's say you have /dev/input/event{0,10}, event5 is a USB keyboard, you unplug it, I assume event5 goes away.

But then you plug in a controller, does this get mapped to event11, or does event5 get reused? Is the behaviour reliable in all versions of linux?

You might argue that metadata should do the trick, but in my experience, on device files, anything beyond read/write is a crapshoot, whether metadata makes any sense is basically a roll of the dice.

So if you have to open device files in order to check their identity, you might as well skip the identity bit and just check if you're a gamepad.

edit: per charcircuit's comment below, it looks like the metadata of /dev/input at least are considered reliable, and this was used to mitigate the issue by checking the mtime of /dev/input itself against a stored timestamp: https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

The actual SDL fix was even simpler, they now just check if the mtime of the /dev/input directory changed: https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

Upstream fixes are nice, but since the game statically links SDL you can't put in a newer version of libSDL.so in the game path and have it patched like that. Are there other ways of patching statically linked binaries with updated functions?

Isn’t this the whole point of using file descriptors? As long as you have an open file descriptor, the kernel resource it references should remain stable. And if the resource is unexpectedly destroyed from under the process’s nose, the file descriptor should report an I/O error the next time you try to read or write from it.

> Isn’t this the whole point of using file descriptors?

Opening the same file multiple times will yield different fds, and the paths can be modified independently of the fd.

The goal here is to find if:

1. there are new input devices

2. which are joysticks (a category which, for SDL, includes gamepads, so basically "has the user plugged in a new gamepad they might want to use for the game")

How would keeping a bunch of fds around help?