You're getting a popup? I'm on Fedora KDE and I get nothing. No popup when turning the controller on, the Settings -> Controller -> Add New Controller page doesn't detect any controller (wired or via puck). The KDE System Settings doesn't detect any controller. It is detected as a mouse though. It works if I want to use the trackpads and buttons as a mouse but that's it. I've opened the KDE mouse settings and disabled the Steam Controller as a mouse device there in case that was interfering with it being detected as a controller but no luck.

Steam and OS both fully up to date
EDIT. I had RT3 turned off... when turning it on Steam won't launch

I'm having this exact issue, where the 'next' button leads to a empty, grey dialog window. People have suggested this is where the firmware update should be happening. I never had RT3 on, it happens on the stable client and the unstable client. Out of curiosity I checked with the RT3 client on and it changed nothing.

I'm on systemd-less gentoo, I can provide any information requested.

Same here (not on T3)

You're getting a popup? I'm on Fedora KDE and I get nothing. No popup when turning the controller on, the Settings -> Controller -> Add New Controller page doesn't detect any controller (wired or via puck). The KDE System Settings doesn't detect any controller. It is detected as a mouse though. It works if I want to use the trackpads and buttons as a mouse but that's it. I've opened the KDE mouse settings and disabled the Steam Controller as a mouse device there in case that was interfering with it being detected as a controller but no luck.

Steam and OS both fully up to date
EDIT. I had RT3 turned off... when turning it on Steam won't launch

At the moment it's the intended behavior (detecting it as mouse)

The issue with the controller not being detected at all was a udev issue. Following the creation of the udev permissions file here fixed it for me: https://www.reddit.com/r/linux_gaming/comments/qs69or/steam_controller_how_to_setup_properly/

Though now when turning the controller on and going through the popup, it says that it failed to update the firmware and to confirm that the controller is securely plugged in, when it's plugged in directly already.

At the very least it's working as a controller

I had the same blank window issue on Gentoo and fixed it by installing dev-libs/hidapi (probably libhidapi on other distros).

That got the firmware update screen to show up, but the update failed. The firmware updater is a separate binary located in .local/share/Steam/bin/hardwareupdater, and running it through strace showed it was getting "permission denied" trying to open /dev/ttyACM0. On my system that file is owned by the dialout group, and running the updater with sudo -g dialout was successful. The udev rule posted above likely would have fixed the permission issue too, so try that before running the updater manually.

I didn't seem to have a permission issue, the hardware updater folder was all in my name and group. But I did have to manually install hidapi for it to work

I had the same issue on NixOS. I put pkgs.hidapi in both environment.systemPackages and programs.steam.extraPackages and that fixed it. I didn't test them one at a time so I don't know which fixed it though.

@robholt u the real MVP

first, i emerged dev-libs/hidapi, which got me past the blank grey screen issue. the firmware update for the puck displayed on the screen. however, it failed the firmware update, like you said it might.

it turns out i didn't have /dev/ttyACM0 as a device on my system as i didn't have CONFIG_USB_ACM set in my kernel. i recompiled the kernel with it enabled. out of curiosity i tried it without adding myself to the dialout group, and it failed. after i added myself to the dialout group, steam completed the firmware update without issue. Cheers!

Oh, interesting, my user is a member of dialout group as I use /dev/tty* devices a lot for the other firmware flashing.

I didn't seem to have a permission issue, the hardware updater folder was all in my name and group. But I did have to manually install hidapi for it to work

Same thing, installed via package manager on fedora and then it works just fine.

It looks like there are three different bugs being discussed in this issue.

Bug 1: The firmware updater tool doesn't bundle its own copy of libhid

Symptoms: The firmware update wizard might get stuck in a blank page.

Fix: We will ship an update to the steam client that correctly bundles these libraries with the firmware updater tool.

Temporary workaround: Install the libhid libraries on the host OS:E.g. for Debian based this would be:

# For debian-ish OSs 
sudo apt install libhidapi-hidraw0 libhidapi-libusb0

# For arch
sudo pacman -S hidapi

Bug 2: Missing udev rules to communicate with the firmware update tty endpoint

Symptoms: The firmware update wizard might get stuck in a blank page or show an error.

The firmware update tool needs permission to communicate with the controller. Steam bundles the necessary udev rules to make this happen in our .deb installer available in our website:
https://store.steampowered.com/about/

Some distros remove these udev rules from the default steam package and ship them in a separate optional package. Usually named steam-devices. If you are using one of these distros, you may need to install the steam-devices package.

Debian and derivatives tend to make steam-devices optional. Arch and derivatives have a separate steam-devices package, but it is installed by default alongside steam.

Fix: Install the steam-devices package if you are in one of the affected distros.

# For debian-ish OSs 
sudo apt install steam-devices

Workaround: Manually install the udev rules. You can also add yourself to the dialout group and reboot as someone else mentioned above, but that only fixes the steam controller, you might run into issues with other devices in the future.

Bug 3: Firmware updates fail when the "Use experimental SteamRT3 client" is enabled

This is the actual issue OP (@agurenko) reported. There was a problem with how the firmware update tool was being run inside the SteamRT3 container. @agurenko I'm going to edit the title and the description of the issue since a lot of people seem to be landing here from links from various places.

Fix: We will ship a fix for this in a future beta.

Workaround: Temporarily opt out of the SteamRT3 beta client.

can confirm the dialout group solution works, at least for me. im on debian 13 here with the stable client, and this was the only thing that worked after having tried everything else in the above comment.

All you have to do on Fedora is run "sudo dnf install hidapi hidapi-devel" and it works.

First my controller did not update at all, now after I ran this on linux mint to install the missing libraries:

sudo apt install libhidapi-hidraw0 libhidapi-libusb0

It beeps multiple times during the update process and switches between a green and a red LED. Steam shows connect and disconnect messages. After a few minutes it fails with this error message:

Steam still says it needs an update when I restart steam or reconnect the controller via cable.

@philippthiele I can take a look at your logs to see what is failing. In your steam client, go to "Help->System Report" and click submit and let me know your steam username and I can take a look at the logs it submits.

Alternatively, you can attach your logs directly to this issue. You can run this command to generate a log archive in your desktop:

tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs

@lostgoat Thanks for the quick support, here is the log archive: steam-logs.tar.gz

@philippthiele your steamui_system.txt log points towards this failure:

Found Type: Triton USB SN: FXA9954900C4B
UPDATING TRITON USB - SN:	FXA9954900C4B
ERROR: Couldn't open BL comport

This means that the firmware update tool doesn't have permission to talk to the relevant device. This is Bug #2 above.

As mentioned above, the installer we distribute has the relevant udev files that give steam permission to access these devices, but some distros don't package them alongside the steam install. Things that you should try:

apt install steam-devices # or the equivalent for your distro

If that doesn't work, you can install the udev rules manually or add yourself to the dialout group and reboot.

Hi @lostgoat,
I had understood it the way that installing steam-devices is the fix while the udev rules are the workaround from how it is described. steam-devices already was installed with steam via apt. What worked now is adding the udev rules as suggested:

sudo curl -L https://raw.githubusercontent.com/ValveSoftware/steam-devices/master/60-steam-input.rules -o /lib/udev/rules.d/60-steam-input.rules
sudo curl -L https://raw.githubusercontent.com/ValveSoftware/steam-devices/master/60-steam-vr.rules -o /lib/udev/rules.d/60-steam-vr.rules
sudo udevadm control --reload-rules
sudo udevadm trigger

Thanks for the help!

I was having issues with my steam controller not connecting even after trying all the steps above. Turns out I installed steam though the ubuntu app center a while back and not through my package manager

# For debian-ish OSs 
sudo apt install steam

Hopefully this helps someone also having this issue

It may be more user friendly to return a different error if there is a permission issue.

This can be checked on the device for the users permission. getfacl will list the user's name separately with "rw" permissions if the latest udev rules with "uaccess" tags are working correctly:

$ getfacl /dev/serial/by-id/usb-Valve_Software_Steam_Controller_Puck_*
getfacl: Removing leading '/' from absolute path names
# file: dev/serial/by-id/usb-Valve_Software_Steam_Controller_Puck_FXB**********-if00
# owner: root
# group: dialout
user::rw-
user:helix:rw-
group::rw-
mask::rw-
other::---

I have observed udevadm trigger not change the uaccess permission but unplugging and re-plugging in the USB cable will get the new permissions correctly.

The steam-devices package on multiple versions of Ubuntu are very old and do not have the update to apply the rule to multiple subsystems, a change that was made back in Sept 2025.

Fixed mine on linux mint 22. Turns out all I needed to do was update my "60-steam-input.rules" file manually. The one I had was from February 2024, I opened it in admin mode, select all and then copy/pasted the contents of the current one from here:
https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules
Saved the file, rebooted PC and the update worked flawlessly.

I had the issue where upon plugging in the controller, it has an error during the firmware update process. I fixed it on NixOS. For me, the solution was this.

• Add pkgs.hidapi to environment.systemPackages = to configuration.nix
• Add programs.steam.extraPackages = [ pkgs.hidapi ]; to configuration.nix
• sudo nixos rebuild switch
• Restart Steam

I am on Mint Cinnamon 22.3 running latest stable Steam Flatpak, and it required two changes to get my controller firmware updated: Fix the missing library and udev permission.

1. Override one of the environment variable hardwareupdater is looking for the libraries libhidapi-hidraw.so libhidapi-libusb.so to be in. No Flatseal permission required.

flatpak override --user --env=LD_LIBRARY_PATH=/home/USERNAME_HERE/.var/app/com.valvesoftware.Steam/.local/share/Steam/linux64/ com.valvesoftware.Steam

1. Manually create the udev rules even tho steam-devices was installed

sudo nano /etc/udev/rules.d/60-steam-controller.rules

# Steam Controller bootloader
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="28de", MODE="0666"

# No reboot required, disconnect/connect the controller required
sudo udevadm control --reload-rules
sudo udevadm trigger

1. Remove the override, Steam needs to fix this:

# to remove it AT THE END ONLY because Steam must fix this: 
flatpak override --user --unset-env=LD_LIBRARY_PATH com.valvesoftware.Steam

https://github.com/flathub/com.valvesoftware.Steam/issues/1545#issuecomment-4449249282

silly thing but mine worked after installing the libapi libraries and the steam-devices I believe. Dont forget to reboot your PC. Also try the steam-beta. Its what worked for me. My controller was now properly taken/seen by steam. Tests return 100% complete. But the main problem here is the update thats supposed to come after that fails.

silly thing but mine worked after installing the libapi libraries and the steam-devices I believe. Dont forget to reboot your PC. Also try the steam-beta. Its what worked for me. My controller was now properly taken/seen by steam. Tests return 100% complete. But the main problem here is the update thats supposed to come after that fails.

Okay, so after doing all I mentioned above and then retrying the beta client, it now appears to be detected and updating.

@All-The-Foxes , I saw you got it working but for future reference.

Mint here but the same should apply.

I had Steam Flatpak working just fine and controller recognised, the moment I installed Steam DEB, the controller was gone.

Steam DEB seems to conflict with steam-devices and remove the package, I had to install it again for Steam Flatpak to see the controller.
And do not use stores, stick with the GitHub package, I have crossed DEB folks experiencing hell coz of using store apps instead of the official one.

So start by making sure steam-devices is installed, it should not be installed anymore.

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

After updating the controller, I am now... back where I started somehow after turning it back on. I'm using Steam installed from apt, not Flatpak, and yes 'steam-devices' is still installed and fine.

you were able to update the controller in steam through the first pop up?

you were able to update the controller in steam through the first pop up?

There was no pop up. I went to controller settings and it showed there that both the puck and the controller had an available update. I installed the update, but before and after that the 'add controller' thing still says there's no controller connected.

That logic has to improve, the first thing you wanna do is to unplug and plug it back but in reality, the Puck firmware is being installed.

When the controller firmware is being updated (after it starts flashing green for you to connect it to the USB-c cable), it changes to a red led, you sure do not wanna unplug it no matter what the no controller pop-up says.

As it is, is very easy for a novice to brick the controller if they are not tailing the log.

That logic has to improve, the first thing you wanna do is to unplug and plug it back but in reality, the Puck firmware is being installed.

When the controller firmware is being updated (after it starts flashing green for you to connect it to the USB-c cable), it changes to a red led, you sure do not wanna unplug it no matter what the no controller pop-up says.

As it is, is very easy for a novice to brick the controller if they are not tailing the log.

Huh? My controller is not bricked. I went to the controller settings, the controller was not listed as connected but listed with the puck under available hardware updates or something similar. I installed the updates. It did the puck first, then did the controller second, and afterward it's still not detected by Steam and still only works as a mouse with the right trackpad.

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

I never said your controller is bricked, I referred to the firmware update process.
It should not be showing those pop-up when the controller is in fact having its bootloader flashed.

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

There were no pop-ups at all for me. No welcome thing, nothing. I had to go to the controller settings and manually start the update. Now that it's up to date I can't do that anymore, so now it's just absent from Steam entirely again.

Edit: Unbinding the puck and controller from hid-generic did not help. Steam still did not do anything with them and replugging just rebinds them to hid-generic.

@All-The-Foxes ... ubuntu has been known to install their snap package when using apt, you can check in terminal with snap list to confirm or rule that out.

@All-The-Foxes ... ubuntu has been known to install their snap package when using apt, you can check in terminal with snap list to confirm or rule that out.

I installed it all the way back on 20.04. It's the apt version. It shows up on apt list as installed, not on snap list.

Also Kubuntu 24.04 here.
Steam (both stable and beta branches, currently on beta) via the official Valve steam.deb file is what is installed.
My udev rules perfectly match what is at https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules as it is at this moment.
Noticed the controller only appeared as hid-generic instead of hid-steam, corrected that, still no change either way.
udevices gives access, but I have it set to 666 for the mode for all hidraw*, uinput, etc... until next reboot (rebooted many times, with all updates applied system-wide as well).
Both libhidapi-hidraw0 and libhidapi-libusb0 are installed.
In short:

• Plug in controller first, it's lizard mode, has 2 ev nodes "Valve Software Steam Controller" and "Steam Controller", the lizardmode events are coming over "Valve Software Steam Controller", the other is silent. Then start steam, lizardmode disables, the ev node of "Steam Controller" vanished, controller does nothing, steam sees no controller, then a minute later the "Steam Controller" reappears and lizardmode is working again over "Valve Software Steam Controller" (which never vanished), which seems to match what I see in the hid-steam code for when the program that told it to switch mode (steam in this case) didn't send further commands for a minute.
• Start steam first, then plug in controller (puck or directly, I've been testing with directly connected primarily), immediately lizardmode with both "Valve Software Steam Controller" and "Steam Controller" evnodes appearing, steam never sees it.

I installed steam via flatpak for testing, aaand... it sees the controller, the controller works, puck too when I use it, it's complaining that it can't update the controllers firmware every time it is started, plugged back in, etc... but it always fails to update it, I verified the steam flatpak has unbounded access to various things in /dev.

Connecting it to my SteamDeck... and it just works, in all ways, and the firmware updated fine on both the controller and puck, bluetooth works too (and bluetooth has the same issues on the ubuntu 24.04, just lizardmode, disables for a minute if steam starts when it's plugged in, etc...).

Here's hoping 26.04 will resolve it when it releases here in a month or 3...
If anyone has other ideas, I'm all ears/eyes. I've tried so many things, including moving to the hardware enablement kernel version 6.17.0-29-generic...

EDIT: Oh, and for completion, it doesn't work over steam link from phone to the Ubuntu 24.04 system either, but it does work over steam link to the steamdeck, which really really makes it sound like something is up with steam?

And yes, both of my OG 2016 Steam Controllers work perfectly in all places in all ways.

That reminds me of something I forgot to mention; I am using the HWE 6.17 kernel and not the 6.8 one.

Reinstalled steam via flatpak

pacman -S --needed --noconfirm hidapi
flatpak install flathub -y --noninteractive com.valvesoftware.Steam

It now appears in the controller list if its plugged in via usb and the input test looks ok with it picking up all inputs but the update popup errors and the inputs do not work outside the input test. The puck is not working at all.

It fails to grab libhidapi

steamui_system.tar.gz

EDIT
Ended up connecting the puck + controller to my steam deck and updating it there

Hi everyone,

I had the same issue on Linux (PikaOS/Ubuntu) with a Steam Controller (Triton) and a Puk (Proteus USB). Steam was stuck in an infinite firmware update loop — the controller kept disconnecting and reconnecting and the update never completed.

Here's what finally worked:

Step 1 — Find the hardwareupdater binary:
find ~/.local/share/Steam -name "hardwareupdater*" 2>/dev/null

Step 2 — Navigate into that folder (mandatory, running it from elsewhere causes a "config file not found" error):
cd ~/.local/share/Steam/bin/hardwareupdater/

Step 3 — List your connected devices and their serial numbers:
sudo ./hardwareupdater.x86_64 --show-all-devices
→ Returns a JSON with all detected devices and whether an update is pending ("must_update": true)

Step 4 — Update each device by serial number:
sudo ./hardwareupdater.x86_64 --update-by-serial <YOUR_SERIAL_HERE>
Repeat for each device listed.

Result: Both my controller and Puk updated successfully, the loop stopped and the wireless connection is now stable.
Key point: On Linux, Steam cannot handle this update on its own. You have to run the binary manually, from its own directory, with sudo, targeting each device by serial number.

Hope this helps someone!

@Tracnardium
Your solution steps work for Steam installed through their Package Manager. For Steam Flatpak it works like this:

Step 1 — Find the hardwareupdater binary:
find ~/.var/app/com.valvesoftware.Steam/.local/share/Steam -name "hardwareupdater*" 2>/dev/null

step 2 — Navigate into that folder (mandatory, running it from elsewhere causes a "config file not found" error):
cd ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/bin/hardwareupdater/

Step 3 — List your connected devices and their serial numbers:
sudo ./hardwareupdater.x86_64 --show-all-devices
→ Returns a JSON with all detected devices and whether an update is pending ("must_update": true)

Step 4 — Update each device by serial number: (Start with the Puck)
sudo ./hardwareupdater.x86_64 --update-by-serial <YOUR_SERIAL_HERE>
Repeat for each device listed.

Reboot PC. Then connect Puck, update then Connect Controller.

Latest Steam client beta and RT3 no longer seem to need libhidapi as a system package. It works without intervention on fedora 44 now.

I haven't tested for the steam flatpak since I don't currently use it but it may also be fixed on beta since I think that was also an issue with not shipping libhidapi.

We've fixed bugs #1 (missing libhid) and #3 (steamrt3c issues) from the post above in the latest steam client beta. So I'm going to close this issue.

If you are running into bug #2, e.g. you need sudo to update or you are experiencing other failures related to permission access, it probably means that the method you used to install steam didn't set up the necessary udev rules correctly. We recommend using the official steam installer or a distro package that mimics it as closely as possible and doesn't strip the udev rule files.

Thanks everyone for all the data submitted here. If you feel like you have further firmware update problems related to the steam client, feel free to open a new issue and attach logs.

wanted to reapte that i am having the same issue on a gentoo install with systemd. i was able to update the controller via a cachy os laptop but i am unable to use non default controls for any steam games IE i am limited to the default xbox style controls basically gimping this controller to a xbox controller.

repeated the issue with the steam beta, and with and without the steam runtime enabled, and when force enabling steam input for games

Just to confirm, running ./hardwareupdater.x86_64 at ~/.steam/steam/bin/hardwareupdater does list and update it properly, steam still doesn't see it at all though, so that's moving to #13250 then.

want to update that that my mention of the steam controller being limited to only to the default xbox layout was due to steam not having proper Wayland support as steam input is hard coded for x11, so i assume it was unrelated to this issue.

Updating the firmware of the controller and puck still doesn't work on my Ubuntu 24.04 machine, even with steam-devices installed, but I've managed to fix it by creating the following udev rules manually:

sudo nano /etc/udev/rules.d/61-steam-controller.rules

Paste the following content:

# Steam Controller Puck normal firmware/update serial endpoint
ACTION=="add|change", SUBSYSTEM=="tty", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1304", MODE="0660", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# Steam Controller Puck bootloader firmware flashing serial endpoint
ACTION=="add|change", SUBSYSTEM=="tty", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1007", MODE="0660", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# Steam Controller normal wired USB mode
ACTION=="add|change", SUBSYSTEM=="tty", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1302", MODE="0660", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# Steam Controller bootloader firmware flashing serial endpoint
ACTION=="add|change", SUBSYSTEM=="tty", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1005", MODE="0660", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

After saving that file, I ran:

sudo udevadm control --reload-rules
sudo udevadm trigger

Unplugged / plugged in the puck, and the firmware update for both the puck and controller worked.

Not sure if this was covered elsewhere, but thought I'd post as this fixed it for me.

@aden-young this fixed it for me. thanks so much! I am on PopOS with KDE Plasma and Steam is not a flatpak.

I've been suffering with this for a few weeks since I bought my steam controller. Controller would work just fine if plugged in direct bypassing the puck. Puck failed to work and dmesg text produced "Not enough bandwidth for new device state.". Then I found this article that said to ensure the device (the puck) was plugged into a physical USB 3.0 port and not a physical USB 2.0 port. This solved my issue.