Powering on the 2015 Steam Controller wirelessly while Steam is running: the controller connects, Steam shows the controller-connected notification, and 1–5 seconds later the client deliberately powers the controller off. This repeats on every attempt, making the controller unusable wirelessly.
logs/controller.txt shows the client failing to read the chip ID over the wireless link and then shutting the controller down:
[2026-09-18 20:06:54] SetLocalControllerConnectionState for 0 to wireless_established because Event from device
[2026-09-18 20:06:54] Steam Controller reserving XInput slot 0
[2026-09-18 20:06:54] Controller Info: HWID: 9, FWTimestamp: 0x57BF5C10
[2026-09-18 20:06:54] Controller Serial# invalid (x4)
[2026-09-18 20:06:54] Controller Chip ID invalid (x8)
[2026-09-18 20:06:54] Failed to ever get Chip ID - shutting down.
[2026-09-18 20:06:54] Turn off Steam Controller
[2026-09-18 20:06:55] SetLocalControllerConnectionState for 0 to disconnected because Event from device
Sometimes the first connect gets further (attributes and serial read successfully, config loads) before disconnecting; the chip-ID failure path above is the most common outcome.
What I have ruled out
Not the kernel driver: unloading hid_steam (modprobe -r hid_steam, receiver interfaces rebound to hid-generic) reproduces the identical Chip ID invalid → shutdown sequence, so the failure is not a race with the in-kernel driver.
Not the controller hardware/firmware: wired via micro-USB (28de:1102), the same client session reads the chip ID successfully and the controller is fully functional (Steam Input creates the virtual X360 pad, games receive input):
Not permissions: the steam-hardware udev rules are installed; the client can open the hidraw nodes and does read the attribute/serial reports over wireless on some attempts.
Not stale firmware in the official channel: controller and dongle both run the newest firmware the client knows; "Force update all connected Steam Controllers" completes in ~1 second with no flash attempted and nothing in the logs.
Not Steam-absent behavior: with Steam closed, the controller connects wirelessly and stays connected indefinitely in lizard mode (mouse/keyboard).
Not batteries: fresh batteries installed 2026-09-16, two days before these logs; no change.
Steps for reproducing this issue
Steam Controller (2015) paired to its 28de:1142 USB receiver; Steam running and logged in (stable 1788652215 or beta 1789781627).
Power on the controller with the Steam button.
Controller connects (Steam shows the connected notification, controller briefly controls the pointer).
Within ~1–5 seconds the client logs Failed to ever get Chip ID - shutting down. / Turn off Steam Controller and the controller powers off.
Reproduces on every attempt (occasionally a connection survives after many power-cycle retries, consistent with a handshake race).
Workarounds
Flashing the 2018 BLE firmware allows the controller to work properly because the 2018 firmware ignores the power-off command and the controller stays connected with working gamepad input.
Your system information
1788652215and public beta buildid1789781627, identical log signature on bothprograms.steam.enable, bubblewrap FHS env),hardware.steam-hardware.enable = true(udev rules60-steam-input.rulespresent and working)0x57BF5C1028de:1142, dongle firmware 1442256398 (Sep 2015, the only release)Powering on the 2015 Steam Controller wirelessly while Steam is running: the controller connects, Steam shows the controller-connected notification, and 1–5 seconds later the client deliberately powers the controller off. This repeats on every attempt, making the controller unusable wirelessly.
logs/controller.txtshows the client failing to read the chip ID over the wireless link and then shutting the controller down:Kernel side, matching timestamps (
journalctl -k):Sometimes the first connect gets further (attributes and serial read successfully, config loads) before disconnecting; the chip-ID failure path above is the most common outcome.
What I have ruled out
Not the kernel driver: unloading
hid_steam(modprobe -r hid_steam, receiver interfaces rebound tohid-generic) reproduces the identicalChip ID invalid→ shutdown sequence, so the failure is not a race with the in-kernel driver.Not the controller hardware/firmware: wired via micro-USB (
28de:1102), the same client session reads the chip ID successfully and the controller is fully functional (Steam Input creates the virtual X360 pad, games receive input):Not permissions: the steam-hardware udev rules are installed; the client can open the hidraw nodes and does read the attribute/serial reports over wireless on some attempts.
Not stale firmware in the official channel: controller and dongle both run the newest firmware the client knows; "Force update all connected Steam Controllers" completes in ~1 second with no flash attempted and nothing in the logs.
Not Steam-absent behavior: with Steam closed, the controller connects wirelessly and stays connected indefinitely in lizard mode (mouse/keyboard).
Not batteries: fresh batteries installed 2026-09-16, two days before these logs; no change.
Steps for reproducing this issue
28de:1142USB receiver; Steam running and logged in (stable1788652215or beta1789781627).Failed to ever get Chip ID - shutting down./Turn off Steam Controllerand the controller powers off.Reproduces on every attempt (occasionally a connection survives after many power-cycle retries, consistent with a handshake race).
Workarounds
Flashing the 2018 BLE firmware allows the controller to work properly because the 2018 firmware ignores the power-off command and the controller stays connected with working gamepad input.
Additional notes
journalctloutput available on request.