Switch Pro Controller Connects via Bluetooth but not Wired

I’m trying to connect my Switch Pro Controller to my Gnome system to play some games. As the title states, it connects without issue through Bluetooth, but the input delay is an issue so I would like to use it with the USB port.

The controller does not respond to being plugged in in any way, and when buttons are pressed acts as it does unplugged (player indicator lights move in scanning pattern for a couple seconds, then stop).
The computer does not respond to the controller being plugged in. The controller does not appear in the lsusb output. The port and cable do allow for data transfer when connected to my phone.

I did not have this issue with my previous system (Arch w/ KDE), where the controller connected simply by being plugged in and pressing a button. I did have this issue on an OpenSUSE install and another Fedora install, both running COSMIC.

I’ve found some more information in Gnome’s logs tool:

 6:16:15 PM kernel: x86/cpu: SGX disabled or unsupported by BIOS.
 6:16:15 PM kernel: ACPI Error: Aborting method \_SB.UBTC.CR02._PLD due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
 6:16:33 PM kernel: Bluetooth: hci0: Reading supported features failed (-16)
 6:16:34 PM kernel: SELinux: systemd-tmpfile (1527) wrote to checkreqprot. This is no longer supported.
 6:16:34 PM bluetoothd: Failed to set default system config for hci0
 6:16:42 PM dbus-broker-lau: Ignoring duplicate name 'org.gtk.vfs.UDisks2VolumeMonitor' in service file '/usr/share//dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service'
 6:16:55 PM gdm-session-wor: gkr-pam: unable to locate daemon control file
 6:17:04 PM kernel: usb 1-4.3: device descriptor read/all, error -32
 6:17:14 PM reporter-system: Process 84312 (bwrap) crashed in execve()
 6:17:24 PM kernel: usb 1-2: device descriptor read/64, error -71
 6:17:24 PM kernel: usb 1-2: device descriptor read/64, error -71
 6:17:24 PM kernel: usb 1-2: device descriptor read/64, error -71
 6:17:24 PM kernel: usb 1-2: device descriptor read/64, error -71
 6:17:25 PM kernel: usb 1-2: device not accepting address 11, error -71
 6:17:26 PM kernel: usb 1-2: device not accepting address 12, error -71
 6:17:26 PM kernel: usb usb1-port2: unable to enumerate USB device
 6:17:26 PM kernel: usb usb1-port2: unable to enumerate USB device

I’ve looked up some of the messages, but haven’t found a solution yet.

After some more research and testing, it seems to me that the most likely problem is the port on the controller. I will still be receptive to input but will stop here otherwise.

I suspect that having it paired with bluetooth at the same time as connected by USB may be the problem. Try to unpair bluetooth, then connect via USB and see if that shows any different performance.

Do you remember what kernel version it was?

this looks familiar to what a totally broken Chinese brand gamepad does when initially connected and pretends to be some kind of Nintendo Pro controller…

pls disconnect the device, start monitoring journal

journalctl -f -n0 --no-hostname

then connect the gamepad and post the output.

it could look like this:

May 22 08:42:12 kernel: usb 1-1.4: new full-speed USB device number 14 using xhci_hcd
May 22 08:42:12 kernel: usb 1-1.4: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 0.20
May 22 08:42:12 kernel: usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 22 08:42:12 kernel: usb 1-1.4: Product: Pro Controller
May 22 08:42:12 kernel: usb 1-1.4: Manufacturer: Nintendo Co., Ltd.
May 22 08:42:12 kernel: usb 1-1.4: SerialNumber: 000000000001
May 22 08:42:12 kernel: usbhid 1-1.4:1.0: can't add hid device: -71
May 22 08:42:12 kernel: usbhid 1-1.4:1.0: probe with driver usbhid failed with error -71
May 22 08:42:12 kernel: usb 1-1.4: USB disconnect, device number 14

note the IDs for idVendor and idProduct ( 057e and 2009 )
disconnect the gamepad and run (replace 057e:2009 with the IDs from your journal output )

echo -n "057e:2009:i" | sudo tee /sys/module/usbcore/parameters/quirks

run the journalctl command again if it’s not active anymore and connect the gamepad.

The kernel was stable, and while I don’t remember the version, it was recent enough that likely would have been the current version (7.0.10.arch1-1).

I did get the controller off of eBay, but I’ve not had reason to suspect it not be authentic. The switch recognizes it as normal (including the colors), and all features work as expected.

The output of the journalctl command is

May 30 02:16:19 kernel: usb 1-2: new full-speed USB device number 20 using xhci_hcd
May 30 02:16:19 kernel: usb 1-2: device descriptor read/64, error -71
May 30 02:16:20 kernel: usb 1-2: device descriptor read/64, error -71
May 30 02:16:20 kernel: usb 1-2: new full-speed USB device number 21 using xhci_hcd
May 30 02:16:20 kernel: usb 1-2: device descriptor read/64, error -71
May 30 02:16:20 kernel: usb 1-2: device descriptor read/64, error -71
May 30 02:16:20 kernel: usb usb1-port2: attempt power cycle
May 30 02:16:21 kernel: usb 1-2: new full-speed USB device number 22 using xhci_hcd
May 30 02:16:21 kernel: usb 1-2: Device not responding to setup address.
May 30 02:16:21 kernel: usb 1-2: Device not responding to setup address.
May 30 02:16:21 kernel: usb 1-2: device not accepting address 22, error -71
May 30 02:16:21 kernel: usb 1-2: WARN: invalid context state for evaluate context command.
May 30 02:16:21 kernel: usb 1-2: new full-speed USB device number 23 using xhci_hcd
May 30 02:16:21 kernel: usb 1-2: Device not responding to setup address.
May 30 02:16:21 kernel: usb 1-2: Device not responding to setup address.
May 30 02:16:22 kernel: usb 1-2: device not accepting address 23, error -71
May 30 02:16:22 kernel: usb 1-2: WARN: invalid context state for evaluate context command.
May 30 02:16:22 kernel: usb usb1-port2: unable to enumerate USB device

It appears the issue occurs early enough that no vendor or product ids are provided to fill the echo command.

Then try using the IDs when connecting via bluetooth. They could be the same. And maybe add also the flag k : 057e:2009:ik

i = USB_QUIRK_DEVICE_QUALIFIER (device can't handle
     device_qualifier descriptor requests);

k = USB_QUIRK_NO_LPM (device can't handle Link
              Power Management);

there are more flags available like g == USB_QUIRK_DELAY_INIT, see kernel documentation (search the page for usbcore.quirks )

according to the linux hardware website the IDs for the Pro Controllers are

Switch Pro Controller      057e:2009 
Switch 2 Pro Controller    057e:2069 

When you’ve found a working setting add the options with grubby to pass it to the kernel on every boot.