Steam client version (build number or date): 1778281814 (May 8, 2026)
Distribution (e.g. Ubuntu): Bazzite 44.20260515 (Fedora-based, kernel 6.x)
Opted into Steam client beta?: No (Stable branch)
Have you checked for system updates?: Yes (system is fully up to date)
Steam Logs: attached as steam-logs.tar.gz
GPU: Nvidia RTX 4090 (driver 595.71.05)
Please describe your issue in as much detail as possible:
When the Steam Controller Puck (dongle) is connected to a USB 2.0 port on the same USB controller as a KVM/monitor hub, the keyboard and mouse become completely unresponsive (no backlight, no input) after switching the monitor's display source away and back to the PC.
Expected: Keyboard and mouse re-enumerate normally after KVM source switch, regardless of other USB devices connected.
Actual: Keyboard and mouse fail to re-enumerate. dmesg shows:
usb 1-9: Not enough bandwidth for new device state.
usb 1-9: can't set config #1, error -28
Root cause: The Steam Controller Puck registers 8 separate HID interfaces on USB 2.0, which exhausts the available 480M bandwidth on the USB controller. When the KVM hub disconnects and reconnects after a source switch, there is no bandwidth remaining to enumerate the keyboard and mouse.
lsusb -t confirms all devices share Bus 001 (USB 2.0, 480M):
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 009: Dev 035, Class=Hub (KVM hub — keyboard & mouse)
|__ Port 011: Dev 002, Class=Hub (monitor hub — Steam Controller Puck on port 11.1)
Workaround: Moving the Steam Controller Puck to a USB 3.0 port places it on a separate USB controller (Bus 002), eliminating the bandwidth contention. Keyboard and mouse re-enumerate correctly after KVM source switches.
Suggested fix: Investigate whether the Puck firmware or Linux HID driver can reduce or consolidate the number of registered HID interfaces on USB 2.0. The current 8-interface design causes bandwidth exhaustion in common multi-device USB setups involving KVM switches or monitor USB hubs.
Steps for reproducing this issue:
Connect Steam Controller Puck dongle to a USB 2.0 port
Connect keyboard and mouse via a KVM hub on the same USB controller (verify with lsusb -t that both share Bus 001)
Switch monitor display input source to a different device (e.g. a laptop)
Switch monitor display input source back to the PC
Keyboard and mouse are now completely unresponsive — dmesg shows error -28 / Not enough bandwidth for new device state
I used Claude to diagnose the issue. I moved my puck to a different usb port and all is working. I thought that you might be interested or will help in supporting other users.
steam-logs.tar.gz
Your system information
steam-logs.tar.gzPlease describe your issue in as much detail as possible:
When the Steam Controller Puck (dongle) is connected to a USB 2.0 port on the same USB controller as a KVM/monitor hub, the keyboard and mouse become completely unresponsive (no backlight, no input) after switching the monitor's display source away and back to the PC.
Expected: Keyboard and mouse re-enumerate normally after KVM source switch, regardless of other USB devices connected.
Actual: Keyboard and mouse fail to re-enumerate.
dmesgshows:Root cause: The Steam Controller Puck registers 8 separate HID interfaces on USB 2.0, which exhausts the available 480M bandwidth on the USB controller. When the KVM hub disconnects and reconnects after a source switch, there is no bandwidth remaining to enumerate the keyboard and mouse.
The Puck registers the following on connection:
lsusb -tconfirms all devices share Bus 001 (USB 2.0, 480M):Workaround: Moving the Steam Controller Puck to a USB 3.0 port places it on a separate USB controller (Bus 002), eliminating the bandwidth contention. Keyboard and mouse re-enumerate correctly after KVM source switches.
Suggested fix: Investigate whether the Puck firmware or Linux HID driver can reduce or consolidate the number of registered HID interfaces on USB 2.0. The current 8-interface design causes bandwidth exhaustion in common multi-device USB setups involving KVM switches or monitor USB hubs.
Steps for reproducing this issue:
lsusb -tthat both share Bus 001)dmesgshowserror -28 / Not enough bandwidth for new device state