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