Optional addon: make gamepads visible to Steam/Proton and in-desktop browsers

[h012193213]

Summary

• Steam / Proton / browsers inside the remote desktop often never see a Selkies pad because the default LD_PRELOAD interposer does not create a real /dev/input device. This PR adds an optional addons/uinput-bridge path (SELKIES_ENABLE_UINPUT_BRIDGE, off by default) that mirrors pads to a kernel Xbox-like controller when /dev/uinput is available.
• Also fixes a general reconnect gap: after WebRTC/page refresh the UI can show a pad while the server drops events (jsN is not connected). Client re-sync + server recreate/associate recover that without enabling uinput.

Addresses #168. Keeps uinput optional per #95 (LD_PRELOAD remains default).

Test plan

• Without SELKIES_ENABLE_UINPUT_BRIDGE: connect over HTTPS, verify gamepad works for LD_PRELOAD apps; refresh/reconnect and confirm buttons still work (no js0 is not connected spam).
• With SELKIES_ENABLE_UINPUT_BRIDGE=true, python-evdev, and /dev/uinput access: confirm a kernel device appears; restart Steam and verify controller detection; check html5gamepad.com inside the remote desktop.
• Confirm default install still does not require /dev/uinput.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[ehfd]

I prefer making Steam / Proton / browsers work in the current architecture, rather.

I did find an issue where a refresh of Selkies makes the gamepad disappear (works on html5gamepad.com the first time Selkies is accessed), so let me fix that, first.

[ehfd]

Can we check this if the uinput requirement is now not needed?

#254 (comment)

The gamepad now works consistently in html5gamepad.com.

[ehfd]

I addressed Also fixes a general reconnect gap: after WebRTC/page refresh the UI can show a pad while the server drops events (jsN is not connected). Client re-sync + server recreate/associate recover that without enabling uinput. in main, and tested both in-container (in-desktop) Firefox and Chrome.

[ehfd]

AI Summary:

/dev/uinput is precisely what this stack is designed to avoid. Selkies targets unprivileged containers (shared Kubernetes / HPC clusters and similar) where /dev/uinput and the kernel joystick devices aren't available at all. That's the whole reason js-interposer (device I/O over a unix socket) and fake-udev (device discovery via an LD_PRELOAD libudev shim) exist — together they let Steam/Proton/SDL/browsers see a pad without any real /dev/input node. So "apps never see a pad because there's no real device" is really a fake-udev/LD_PRELOAD coverage question: when a consumer doesn't see the pad, it's almost always because the preload (usually fake-udev) isn't reaching that process — and in our target environments a /dev/uinput fallback wouldn't be available anyway. There's also a practical snag: with the bridge on and the interposer pads still present, an app that can see both would enumerate the controller twice.

If you're hitting a specific app the interposer genuinely can't reach — Proton's pressure-vessel sandbox is the usual suspect, since it can stop both the preload and the socket from crossing the namespace — I'd love to dig into that with you and fix it at the interposer/preload layer. That keeps it working in the unprivileged case, which a uinput path can't.

On the reconnect fix: good catch, and the diagnosis is exactly right — but that one's already handled on main. input._resyncGamepads() re-announces connected pads on every re-attach (WebRTC data-channel reopen, and the page reload the WS path does), and the server keeps persistent, adopt-on-reconnect gamepad instances so the association re-binds without recreating a device. It landed in c8520e6.