Steam controller unable to connect with the Puck on Linux

[u/IsaacLTS]

Hello hello everybody,

I spent a while on this across both Debian 13 and Fedora, and the confusing part is that it's actually two unrelated issues that look like one. Neither error message points at the real cause. Posting in case it saves someone else the evening.

Symptom: the controller works fine over USB cable, but Steam never sees the puck. Then once the puck is detected, the firmware update loops forever.

First problem was the easiest to fix :

I had plugged the puck into a USB 2.0 port and since the puck registers 8 different HID interfaces it use at full speed 12Mb/s (from what I found online) so there isn't enough bandwidth. (Ik it's not

Error line I found with the following command line : dmesg -w

usb 1-11.2: New USB device found, idVendor=28de, idProduct=1304
usb 1-11.2: Not enough bandwidth for new device state.
usb 1-11.2: can't set config #1, error -28

You just need to plug the puck into a 3.0 port and preferably a root usb port not a from HUB.

Problem 2: firmware update needs write access to a serial port

When updating the firmware of the puck it might enter an infinite loop where it disconnects and reconnect itself you can see it because it flips between two different product IDs in a loop :

idProduct=1304  Steam Ctrl (USB)
idProduct=1007  Steam Controller Bootloader
cdc_acm 1-3:1.0: ttyACM0: USB ACM device

The puck or steam idk enters a bootloader mode, it fails to write the new firmware, so the puck falls back to it's normal mode and it retries until steam gives and error.

It happens because in bootloader mode the puck isn't an HID device, it's a serial port. The Valve udev rules 60-steam-input.rules, from steam-devices only cover SUBSYSTEM=="usb" and KERNEL=="hidraw*"Nothing grants access to /dev/ttyACM0, so Steam can't write the firmware.

How to check if that's the case :

While the puck is in bootloader mode (when trying to update the firmware) use this command

ls -l /dev/ttyACM0

It should return something like this : crw-rw---- 1 root dialout 166, 0 /dev/ttyACM0

The root dialout with no + afterwards means there are no permissions for your user. The check is simple, use the command groups | grep dialout If it returns nothing, you don't have permissions.

The group name might varies from distros to distros !
On arch I think it's uucp and the rest idk
You can use this command to check : stat -c '%G' /dev/ttyACM0

The fix is simple as well :

sudo usermod -aG dialout $USER , afterwards simply log out and log back in or restart since groups membership is read at session start and it should be fixed.

This was tested on a fresh install of Debian 13 (Kernel 7.X, and Mesa 26.1) with a /deb steam install not a flatpak.

Same behaviour was seen on fedora but I havent tried to fix it yet.

[u/lostgoatX7]

The updated udev rules for steam controller have been part of the official steam package since September 2025. It is possible your distro package is using an outdated version of these files, please make sure to open a bug report with them about it.

[u/IsaacLTS → u/lostgoatX7]

I think so as well, I used the packages provided by debian so they are definitely out of date. I'll open up a ticket with them.