4 ms·

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 s

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.

pas 5y ago
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!? :(
- flohofwoe 5y ago
  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.
  - Vvector 5y ago
    Or maybe just poll for new input devices when the game is paused, or before the game starts.
    - flohofwoe 5y ago
      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.
  - yjftsjthsd-h 5y ago
    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)
yxhuvud 5y ago
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?
asdfasgasdgasdg 5y ago
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.
- dkersten 5y ago
  SDL has an event for when a new gamepad is detected or removed: http://wiki.libsdl.org/SDL_ControllerDeviceEvent 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 http://wiki.libsdl.org/SDL_GameControllerOpen
- fleabitdev 5y ago
  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/getting-started-with-xinput#getting-controller-state 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.
  - Sharlin 5y ago
    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…
charcircuit 5y ago
SDL wants to support hotplugging where you can plug a controller in after you have already started the game.
- deleted 5y ago
  [deleted]
- vlovich123 5y ago
  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.
  - Sharlin 5y ago
    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.
smcameron 5y ago
SDL should probably use inotify() on linux so the kernel can let it know when /dev/input has changed rather than polling it.
- nemetroid 5y ago
  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/d0de4c625ad26ef5401665ca26b5f2c0fb76e91b/src/joystick/linux/SDL_sysjoystick.c#L656 https://github.com/libsdl-org/SDL/blob/d0de4c625ad26ef540166...
  - Sjonny 5y ago
    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?
    - touisteur 5y ago
      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.
    - cesarb 5y ago
      > 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.
      - Sjonny 5y ago

pas 5y ago

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!? :(

flohofwoe 5y ago
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.
- Vvector 5y ago
  Or maybe just poll for new input devices when the game is paused, or before the game starts.
  - flohofwoe 5y ago
    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.
- yjftsjthsd-h 5y ago
  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)

yxhuvud 5y ago

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?

asdfasgasdgasdg 5y ago

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.

dkersten 5y ago
SDL has an event for when a new gamepad is detected or removed: http://wiki.libsdl.org/SDL_ControllerDeviceEvent 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 http://wiki.libsdl.org/SDL_GameControllerOpen
fleabitdev 5y ago
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/getting-started-with-xinput#getting-controller-state 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.
- Sharlin 5y ago
  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…

charcircuit 5y ago

SDL wants to support hotplugging where you can plug a controller in after you have already started the game.

deleted 5y ago
[deleted]
vlovich123 5y ago
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.
- Sharlin 5y ago
  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.

smcameron 5y ago

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

nemetroid 5y ago
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/d0de4c625ad26ef5401665ca26b5f2c0fb76e91b/src/joystick/linux/SDL_sysjoystick.c#L656 https://github.com/libsdl-org/SDL/blob/d0de4c625ad26ef540166...
- Sjonny 5y ago
  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?
  - touisteur 5y ago
    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.
  - cesarb 5y ago
    > 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.
    - Sjonny 5y ago