Seems like SDL stopped working now

SDL has been updated to 3.4.10...

Hopefully Valve is able to pull the fixes in...

https://github.com/libsdl-org/SDL/releases.

My steam Controller stopped working too, since a specific update, What I can see is that in the KDE Gamecontroller GUI
no inputs are recognized:

even if the popup of steam says "gamepad mode"

Is this the same issue, or a different one?

I am on Manjaro KDE systemd 260 and Plasma 6.6.5

I think its the same issue. Glad to see I'm not alone. From what @Riueus mentioned above, there is a dependency on a library called SDL which needs to be updated for the controller. This had to get updated to 3.4.10 which happened yesterday. Fingers crossed, Valve will add it in to their beta channel this week.

I think its the same issue. Glad to see I'm not alone. From what @Riueus mentioned above, there is a dependency on a library called SDL which needs to be updated for the controller. This had to get updated to 3.4.10 which happened yesterday. Fingers crossed, Valve will add it in to their beta channel this week.

Not quite the case, What is needed to be updated is the system with lastest sdl3 pkg not valve's firmware

Not quite the case, What is needed to be updated is the system with lastest sdl3 pkg not valve's firmware

"The system" is meant, I need to update the pkg that is delivered with the operating system, or is it delivered with steam/controller driver from valve?

https://github.com/ValveSoftware/steam-for-linux/issues/13286

Edit: Only for info: I use snap version in Ubuntu

UPDATED: With the DEB version, it recognized it without any problems.

WITH SNAP-version there are always problems,

EDIT: im using Proton 11 if that helps:

Quick update,

As of the latest beta version , using proton experimental the controller is working again. It looks like SDL was updated in the Ubuntu folders of Steam.

I am using steam beta too:

team Beta Branch:  Steam Beta Update
Steam Version:  1780352834
Steam Client Build Date:  Tue, Jun 2, 2026 12:04 AM UTC -08:00
Steam Web Build Date:  Mon, Jun 1, 2026 11:43 PM UTC -08:00
Steam API Version:  SteamClient023

on my pc it is not working yet.

I am using steam beta too:

team Beta Branch:  Steam Beta Update
Steam Version:  1780352834
Steam Client Build Date:  Tue, Jun 2, 2026 12:04 AM UTC -08:00
Steam Web Build Date:  Mon, Jun 1, 2026 11:43 PM UTC -08:00
Steam API Version:  SteamClient023

on my pc it is not working yet.

Quick check - what are you using for the capability layer by default? I noticed as part of testing that games where it still wasn't working I was using proton-ge.

Switching to a steam provided proton that's when I saw it work again. Just to be clear I changed protons before I raised this issue. It's was broken on all of them. I'm assuming the steam protons use their version of SDL not the system.

Quick check - what are you using for the capability layer by default? I noticed as part of testing that games where it still wasn't working I was using proton-ge.

Switching to a steam provided proton that's when I saw it work again. Just to be clear I changed protons before I raised this issue. It's was broken on all of them. I'm assuming the steam protons use their version of SDL not the system.

In my case, as it has worked, proton was not active yet. I just needed to open steam, then then controller registered itself in the game mode and then the crosshair in the Gamecontroller Tool of KDE moved around and the buttons worked too.

Since some update that stopped and no game is working independently of the proton version.

I am using the latest cachy-Proton with crimson desert, because valve still did not manage to get HDR without gamescope working in their build.

Funny enough my controller works in VRChat just fine, but other games like Party Animals do not detect it and neither does Steam itself. Ubuntu 24.04, HWE kernel 6.17.x, Steam installed through apt.

Funny enough my controller works in VRChat just fine, but other games like Party Animals do not detect it and neither does Steam itself. Ubuntu 24.04, HWE kernel 6.17.x, Steam installed through apt.

Simple explanation:

1. Valve first party all udpate to SDL3
2. Some games or legacy games will never update to SDL3

Meaning: Best way to use steam controller is steam input, can forget about SDL3 for now at least in linux.

I just received my controller last week and I am experiencing similar issues. I assume it's something to do with XWayland not properly initializing? I am not the most familiar with this process.
The only game I have found to be working has been Silksong which probably just has native Steam Deck/Controller support.

• OS: CachyOS
• DE/WM: Niri but I have tried Gnome with similar results. Also the Big Picture mode is unusable due to lag and latency
• GPU: RTX 4070 Super
• Steam Beta: Enrolled
• Controller: Up-to-date
• Tried standard proton, ge-proton, proton experimental. No change
• Had to install extest for desktop configuration to work too. Controls the desktop just fine now but I lose all control when I launch a game.

Is this something I should contact Valve support about? Controller works flawlessly with my Deck.

I do not know what it has to do about that SDL. @Riueus Is your controller working in the OS gamepad UI again, or not? Because BEFORE a specific firmware updated that worked and EVERY game worked too when I loaded steam. Now no game is working and the tool is even not showing any movement either.

Not sure if this helps, in my case switching to a Valve version of proton helped. GE and Catchy no longer work. As with your findings that wasn't the case prior to the May 18th Firmware.

Well GE hasn't seen an update in months now. It could just be missing something that's present upstream.

So you all want to tell, that the steam controller pass-tru to the operating system was a mistake at all and never should have worked?

For me it's working again.
My fix was upgrading to the latest Kernel 7.1 and probably adapting the udev rules from steam to set world readable as described here:
https://wiki.archlinux.org/title/Gamepad#Steam_Controller

However the new controller seems to have more and different entries:

I've used the following ones to the new directory:
/etc/udev/rules.d/99-steam-controller-perms.rules

# Valve USB devices
SUBSYSTEMS=="usb", ATTRS{idVendor}=="28de", MODE="0666", TAG+="uaccess"

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666", TAG+="uaccess"

# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666", TAG+="uaccess"

Seeing something similar to this issue as well. Lizard mode works on the steam controller when steam is NOT on, as soon as I start Steam, the controller stops responding (still getting haptic feedback from trackpad and triggers though). This also translates to all games not accepting Steam Input from the controller, though when I hold start (and enter gamepad mode) the controller functions fine.

To add, I am using Wayland (Hyprland) on CachyOS

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/13251#issuecomment-4808160589

This fixed my issue as well! I think perhaps my specific issue was that I'm using flatpak steam, so it didn't install any udev rules at all? Steam was unable to recognize my controller or puck at all, although the right pad still worked as a mouse. After installing these udev rules and rebooting, everything started working perfectly.

The apt version of Steam didn't install them either.

I removed all the custom udev rules I placed into /etc/ trying to get the controller working, figuring they might be interfering in some way, then updated the /lib/udev/rules.d/60-steam-input.rules to the latest upstream version instead of the 2024 version I had there. Reloaded the rules, triggered, restarted Steam, and no change. It still can't see the controller. I'm going to leave the rules alone at this point, since that doesn't seem to be my issue.

Ubuntu 24.04 on HWE kernel 7.0.0-28

Confirming this on Bazzite (Fedora atomic) with the 2026 Steam Controller, with some additional findings that I think narrow down where the failure happens.

Summary: the client resolves the 2026 controller to controller_neptune at config-selection time, in memory, before any config file is read. Because of that, no file-level correction has any effect, and every game falls back to AppID 413080 (desktop config), leaving the controller in keyboard/mouse emulation inside games.

System information

• Distribution: Bazzite stable 44.20260802 (Fedora 44, atomic), kernel 7.1.5-ogc5.1.fc44.x86_64
• Steam client build: 1785799196, build date Mon 3 Aug 2026, Stable branch, native (non-Flatpak) install
• Opted into Steam client beta: No
• Session: KDE Plasma on Wayland
• Hardware: AMD Ryzen 7 7800X3D, Radeon RX 7900 XTX (Navi 31)
• Controller: Steam Controller (2026), firmware current, enumerating as 28de:1304 Valve Software Steam Controller Puck
• Test game: BeamNG.drive (AppID 284160, v0.39.4, Proton)

Symptoms

In games the controller behaves as lizard mode / desktop config: sticks and pads emit mouse movement, R2 emits a mouse click, R1 emits Left Alt, D-pad emits arrow keys. The game enumerates a device named "Steam Controller" but receives no gamepad input from it. Steam Input is set to forced on for the game with a gamepad template assigned. Reproduced both wired over USB-C with the puck removed and wirelessly via the puck. Bluetooth was not involved.

Regression boundary

controller.txt shows normal per-game activations for AppID 284160 running from February through 24 June 2026, then stopping entirely. Every activation after that date is 413080. Nothing about the game or the system changed at that point. This is still reproducing on the current Stable client (build 1785799196, 3 August 2026), roughly six weeks after the regression began.

Key finding: controller type is resolved to neptune in memory

This is the part I have not seen reported. On a fresh client start, with the triton configset already pointing at a triton template, the client still selects the neptune template:

[2026-08-18 13:04:16] SetSelectedConfigForApp - idx 0 app: 284160, 0 controller_neptune_gamepad_fps.vdf 0 0
[2026-08-18 13:04:19] Queueing activation for controller: 0 app: 413080

The neptune filename here does not come from any file on disk, since the on-disk triton entry names a different file (see below). It is produced by the client's own controller-type resolution, which means the identity mismatch happens before config lookup, not during it.

Supporting evidence

1. No triton template ships with the client.

~/.local/share/Steam/controller_base/templates/ contains:

controller_android_gamepad_fps.vdf
controller_apple_gamepad_fps.vdf
controller_generic_gamepad_fps.vdf
controller_mobile_touch_gamepad_fps.vdf
controller_neptune_gamepad_fps.vdf
controller_ps3_gamepad_fps.vdf
controller_ps4_gamepad_fps.vdf
controller_ps5_gamepad_fps.vdf
controller_xbox360_gamepad_fps.vdf
controller_xboxone_gamepad_fps.vdf

There is no controller_triton_* template of any kind.

2. Assigning a gamepad template writes it under the neptune identity.

After selecting a built-in Gamepad template for BeamNG in the UI:

$ grep -A2 284160 configset_controller_*.vdf
configset_controller_neptune.vdf:       "284160"
configset_controller_neptune.vdf-       {
configset_controller_neptune.vdf-               "template"    "controller_neptune_gamepad_fps.vdf"
--
configset_controller_triton.vdf:        "284160"
configset_controller_triton.vdf-        {
configset_controller_triton.vdf-                "workshop"    "3732467569"

The entry lands in the neptune configset. This matches the original report in this issue.

3. Hand-corrected config files persist and are still ignored.

With Steam fully shut down I copied the neptune configset contents into configset_controller_triton.vdf, created controller_triton_gamepad_fps.vdf from the neptune template with "controller_type" "controller_triton", and pointed the triton configset at it:

$ grep -A2 284160 configset_controller_triton.vdf
        "284160"
        {
                "template"    "controller_triton_gamepad_fps.vdf"

These files survive a Steam restart unmodified, so this is not a write race or a file being clobbered. The client simply never uses them, and still logs the neptune selection quoted above.

I also populated the per-serial configset (configset_FXA<...>.vdf, which ships empty at 24 bytes) with the same contents. No effect.

Differences from the original report

• No Deck Controller PCB Serial# invalid: NA spam in my logs
• configset_controller_triton.vdf exists on disk and is found at runtime (found ibex config set file on-disk), it is just empty of game entries
• Same end result regardless, which suggests the Deck serial errors are a separate symptom rather than the cause

Additional notes

/sys/bus/hid/drivers/hid-steam/ has no bindings, so the kernel driver does not claim this controller. That means Steam Input is the only path to gamepad input on Linux for this device, and when the config resolution fails there is no fallback at all: the game receives lizard-mode keyboard and mouse events and nothing else.

Expected behaviour

The client should resolve the 2026 controller to controller_triton, ship triton templates, and write per-game configs under the triton identity so they can be found at runtime.

Attachments

• controller.txt
• configset_controller_neptune.vdf
• configset_controller_triton.vdf
• configset_controller_xbox360.vdf
• template directory listing

steam-13251-controller.txt
steam-13251-excerpt.txt

Confirming this on a second independent Bazzite install, with evidence that broadens where/how it reproduces.

System: Bazzite stable 44.20260820.0 (Fedora 44 atomic), kernel 7.2.0-ogc4.1.fc44.x86_64, Steam client build 1785799196 (stable branch, native non-Flatpak). GNOME on Wayland. Controller: Steam Controller (2026), wireless via the puck dongle, 28de:1304.

Symptom matches exactly: mapping uses xinput : false persists regardless of which controller layout/template is assigned to a game; games receive no gamepad input at all; only desktop/keyboard-mouse-style input (or, in Big Picture, the Steam-button chord) responds. Tested with Warhammer 40,000: Space Marine 2 (AppID 2183900) - controller has never worked in this game in any session.

Two things worth adding to the picture:

1. This isn't limited to in-game - the same virtual-device churn/misbehavior reproduces with no game running at all, just idling in Big Picture. Watching journalctl -k | grep "X-Box 360 pad" with every game closed still shows Steam's virtual XInput device being torn down and recreated repeatedly (5 times in 15 minutes in one idle session), alongside controller.txt showing exactly the AppID-thrashing pattern described above (cycling between 413080/desktop and 443510/Steam-button-chord). So whatever's causing the misidentification appears to be live and active even before a game is ever launched, not something that only triggers at game-launch time.

2. Clean isolation via a second controller: paired an unrelated generic Bluetooth gamepad and tried the same game - it works correctly. Checked controller.txt and that controller is also managed through Steam Input, also shows mapping uses xinput : false, but works fine - so whatever's broken is specific to how the client identifies/handles this controller model, not a general Steam Input "native API" problem. Consistent with the in-memory codename-resolution bug described above - a device that doesn't get misresolved to neptune in the first place behaves normally.

No workaround found on my end either - can confirm the file-level config edits/udev rule changes discussed upthread don't touch this, consistent with the "resolved in memory before any file is read" finding.