3 ms·

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

masklinn 5y ago
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/59728f9802c7869a9b47d6176296086dc0d00d45 https://github.com/spurious/SDL-mirror/commit/59728f9802c786...
- 10000truths 5y ago
  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.
  - masklinn 5y ago
    > 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?
- pdw 5y ago
  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/59728f9802c7869a9b47d6176296086dc0d00d45 https://github.com/spurious/SDL-mirror/commit/59728f9802c786...
  - Sjonny 5y ago
    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?

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/59728f9802c7869a9b47d6176296086dc0d00d45 https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

10000truths 5y ago
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.
- masklinn 5y ago
  > 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?
pdw 5y ago
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/59728f9802c7869a9b47d6176296086dc0d00d45 https://github.com/spurious/SDL-mirror/commit/59728f9802c786...
- Sjonny 5y ago
  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?