godot: Controller reconnection does not emit `joy_connection_changed` signal on Steam Deck

Godot’s joypad hotplugging code is current either/or, using udev if found, and falling back to parsing /dev/input/ manually otherwise. But apparently udev is unusable in a sandbox so indeed we’d have to do like SDL2 and do a best attempt at detecting whether we’re sandboxed

Yes, SDL’s approach is the least-bad way to deal with this. The Steam container runtime cannot make this work more transparently than it already does, because we’re constrained by how udev and evdev were designed. If Godot doesn’t use SDL, then it’ll be necessary to reinvent essentially the same logic that SDL uses, including having a heuristic to decide which input devices are gamepads suitable for your game and which ones are accelerometers or other weird things which should be ignored unless supported, based on their evdev capabilities and/or the information in /sys.

Another possible route would be to treat SDL as being a “platform library” on Linux, analogous to how you presumably use DirectX interfaces on Windows, and build higher-level interfaces over the top of it where needed. Some other game engines already work that way, and so does Proton.

I’ve thought about providing a shim/modified libudev that fakes the information you would have seen on the host system by using IPC to a service running the real libudev outside the container; but libudev’s API is really at too low a level for that to be particularly feasible, so this is unlikely to happen.

The reason this is different on Steam Deck is that the Steam Deck’s operating system is a fast-moving rolling release based on Arch Linux, so it’s too much of a moving target to be reasonable for games to run on it directly or via the legacy LD_LIBRARY_PATH Steam Runtime - that would come with a high risk of games working in 2023, but failing to work in 2025 or 2030 when the operating system has changed too much for them to keep up with. Instead, by default native Linux games on Deck run in the Steam container runtime (specifically the scout-on-soldier version, which provides ABI compatibility with the legacy LD_LIBRARY_PATH runtime). That’s designed to be more a stable thing to support for years to come.

It is also possible to opt-in to using the newer, legacy-free Steam Runtime 3 “sniper” container runtime by editing a game’s metadata, but at the moment there’s no interface for that in Valve’s partner web-UI, so that change can only be done with help from a Valve developer. When sniper becomes available on a self-service basis, I suspect that the developers of games based on open source engines like Godot will want to start targeting that preferentially, with binaries built in a sniper container.

On desktop Linux, you can force a game to use the same runtime as on the Deck via Properties -> Compatibility -> Force the use of -> Steam Linux Runtime (behind the scenes, that’s the scout-on-soldier container runtime). You should find that you get the same results as on Deck: if you’re relying on udev for device enumeration, then controllers that are already there at startup (in particular the built-in controls) will often work, but hotplugging USB controllers or connecting Bluetooth controllers during gameplay usually won’t, because the notification that says a new controller was connected doesn’t arrive in your game code.

Running a game as a Flatpak app, or inside a Flatpak app like the unofficial Flatpak version of Steam (even without using the Steam container runtime), would have exactly the same issues as in the Steam container runtime for essentially the same reasons. That’s why SDL detects both.

Would I lose anything important by switching all my builds to udev=no?

The main thing that you get from udev, beyond what you can get from /dev and /sys, is that udev rules can mark devices with metadata like ID_INPUT_JOYSTICK and ID_INPUT_ACCELEROMETER according to a heuristic and/or a database of known devices. When accessing devices directly, you don’t get access to that information, so either game, engine or library code needs to implement a heuristic to figure out what each device is, so that you won’t accidentally treat an accelerometer/gyro as a joystick and move the player character around when the device is tilted. I would personally recommend SDL’s approach: use libudev when running directly on the host system, or access /dev and /sys directly when a container is detected.

I have some merge requests open in SDL to improve its heuristic. If Godot isn’t using SDL, then it might be necessary to track changes like those and apply the equivalent in Godot.

(PS: I haven’t got much further with Cassette Beasts than the point the demo ended at, but I’m enjoying it and will be recommending it to friends 😃

it prefers the steam input rebindings first and foremost, and ignores the original hardware

I’m not a Valve or Steam Input developer, but I believe this is how Valve want games/engines/middleware to deal with Steam Input legacy mode bindings.

(What they would ideally like games to do is the action-based API, where the game uses the Steamworks API to tell the Steam Input layer what “actions” the game has, in terms of game-specific abstract verbs like “jump” and “talk to NPC” rather than game controller buttons like A and X, and then receive events from Steam Input in terms of those abstract game-specific actions, with the player able to remap those abstract actions to a button of their choice. But I suspect that’s probably something that can only usefully be implemented per-game, and difficult to do in a generic game engine that can’t know what gameplay mechanics the game will have.)

Is there an upstream bug report about this? If it happens also in non Godot games that’s indeed pretty relevant for Valve to look into.

I could only find a pretty lengthy thread on Steam forums about this when I was looking it up last, as I was confused to why it was working through my desktop steam client w/ steam input but uniquely not on the Steam Deck. However, I can’t find it right now – I’ll comb through my laptop history to see if I can find it again.

What I do know is that the existing MR fixes this bug when launching a game through steam that has steam input enabled and also gives preferential treatment to the users desired keybinds (as in, it prefers the steam input rebindings first and foremost, and ignores the original hardware.) There might be ways to work around this issue if we create a work around for STEAM_DECK=1, but I haven’t found a clean solution yet. I’ll keep you updated.

edit: I didn’t find the exact thread I saw but I found this thread which seems to be a similar unresolved issue occurring on multiple (non-godot) games. I think Valve will probably fix it once they add proper controller “order” reassignment, as I think their current external controller support is a bit of a band-aid to the fact that the deck controller is always considered the “first player” by order at which the controllers are connected. The problem is that Valve can be kind of hard to know what they plan with regards to their roadmap, so it might be worth me making a thread on the bugs section to highlight this particular issue (or perhaps bring it up with people of interest via direct email.)

#76961 should fix this for 4.x (4.0.3 and 4.1), and #76962 for 3.x (3.5.3 and 3.6). I tested the 3.x version successfully with Cassette Beasts, wrote some details in #76962.

We parse SDL_GAMECONTROLLERCONFIG (and use the same mapping format as SDL does), but we’re not checking SDL_GAMECONTROLLER_IGNORE_DEVICES. Thanks for the hint, I’ll look into this.

I still plan to look into this for another PR.

Thanks for your detailed input, that’s very helpful! We’ll definitely have to go with a SDL like approach (or give up and integrate SDL, but we try to keep our thirdparty dependencies as lean as possible).

The current non-udev fallback code indeed polls /dev/input every second currently: https://github.com/godotengine/godot/blob/master/platform/linuxbsd/joypad_linux.cpp#L214-L235

And then we have some barebones checks to validate what may or may not be a joystick: https://github.com/godotengine/godot/blob/master/platform/linuxbsd/joypad_linux.cpp#L323-L386

It’s relatively old code which has been improved a bit over the years but still has some issues (#59412). Things mostly work, until they don’t as seen here 😃

When sniper becomes available on a self-service basis, I suspect that the developers of games based on open source engines like Godot will want to start targeting that preferentially, with binaries built in a sniper container.

As a side note, to ensure maximum portability in Godot, we typically link all our thirdparty dependencies statically, aside from the ones which are too close to the OS, which we instead dlopen (and have fallback code when missing), such as X11, pulseaudio, alsa, dbus, udev.

So Godot’s requirements on the host system are fairly low, and in my experience Godot games don’t require the Steam Linux Runtime at all:

$ ldd /media/data/Games/Steam/steamapps/common/Cassette\ Beasts/CassetteBeasts.x86_64 
        linux-vdso.so.1 (0x00007ffd275e3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0f1eeb9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0f1f0c1000)
        libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f0f1eead000)
        libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f0f1eea8000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007f0f1ee94000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f0f1ee87000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f0f1ee79000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007f0f1ed3a000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00007f0f1ed27000)
        libGL.so.1 => /lib64/libGL.so.1 (0x00007f0f1eca1000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0f1ec9c000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0f1ec97000)
        libsteam_api.so => not found
        libm.so.6 => /lib64/libm.so.6 (0x00007f0f1ebb9000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f0f1ebb1000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f0f1eb8a000)
        libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f0f1ead1000)
        libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f0f1ea9b000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007f0f1ea96000)
        libXdmcp.so.6 => /lib64/libXdmcp.so.6 (0x00007f0f1ea8e000)

With Godot 4 we even load X11, GL, or Vulkan dynamically (and soon Wayland), so the dependencies are very lean:

$ ldd ~/Projects/godot/stable/4.0/Godot_v4.0.2-stable_linux.x86_64 
        linux-vdso.so.1 (0x00007ffe587f9000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1e56b79000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f1e56b74000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f1e56a98000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f1e568c6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1e56bb4000)

So those binaries should be fairly portable, whether running in Steam or standalone (and users typically don’t build them against the Steam Runtime, but just use our prebuilt portable binaries)… At least until glibc’s next soname change 😛

Note that because udev doesn’t guarantee compatibility between one version of udevd and a different version of libudev, this cannot actually be guaranteed. In practice it usually works now, so the Steam container runtime doesn’t go out of its way to break this interface; but we can’t be confident that in 2025 or 2030 it will still work.

Yeah that’s where for Godot specifically, not using libudev from the Steam Runtime but dlopen’ing the one from the host OS which would match udevd should hopefully work better.