Wired controller keeps disconnecting

Recently I came across a very strange issue where my wired controller will keep disconnecting and reconnecting. I have been using this controller for months with no issues until just this week. I have tried to troubleshoot it to no avail.

Hardware details:
Controller: Gulikit Zen Pro controller (identical to the King Kong 2 Pro controller) model NS-09
USB-C to USB-A cable that came with the controller
System: Lenovo Legion 5 15ARH05

Software details:
Playing games through Steam using Steam Input
EndeavourOS (obviously)
All packages up to date. Steam up to date
Controller firmware was last updated when I bought it in October 2023. I doubt this is the source of the issue as it started recently. I also just don’t really want to deal with Gulikit’s frankly strange firmware upgrade process again.

Issue:
The controller can turn on and connect just fine. However, it will then disconnect and start looping disconnect/connect, with periods of connection typically being quite short (<5 sec). Sometimes it’ll stay connected for longer, particularly when an input is being continuously sent. This continues until a reconnect doesn’t happen for long enough that the controller turns off and stops connecting. This behavior is consistent across the Switch Pro Controller, xinput, and mobile phone controller modes of operation (Steam doesn’t connect to it in dinput mode). This issue occurs consistently both in the steam menu and in games.

Things I have tried, based on suggestions from across the internet:

Turning everything involved off and back on again, multiple times. No effect.

Changing which USB port on the laptop I am using. No effect. Unplugging all other USB devices. No effect.

Disabling controller rumble in steam settings (tried this on xinput mode). No effect.

Blacklisting the hid_nintendo kernel module (only affects Switch Pro mode). Rebooted. No effect. This module remains blacklisted.

Booting with the kernel parameter usbcore.autosuspend=-1. Confirmed this took effect with cat /sys/module/usbcore/parameters/autosuspend returning -1 (it’s usually set to 2). No effect. This value is back to its default now.

Installing TLP. This conflicted with power-profiles-daemon. This didn’t help, so I have reinstalled power-profiles-daemon instead.

I’ve also taken a look at the system journal, but I couldn’t determine what the problem was. I’ve reproduced one connection cycle on Switch Pro mode below.

(My journal is clogged with rtkit-daemon: Failed to look up client: No such file or directory. I’ve removed those lines as I doubt they’re relevant and there’s a lot of them. I can put them back in if their position is important.)

journalctl output for the duration of a connection cycle
Apr 27 03:05:30 hostname kernel: usb 1-2: new full-speed USB device number 5 using xhci_hcd
Apr 27 03:05:30 hostname kernel: usb 1-2: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
Apr 27 03:05:30 hostname kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 27 03:05:30 hostname kernel: usb 1-2: Product: Pro Controller
Apr 27 03:05:30 hostname kernel: usb 1-2: Manufacturer: Nintendo Co., Ltd.
Apr 27 03:05:30 hostname kernel: usb 1-2: SerialNumber: 000000000001
Apr 27 03:05:30 hostname kernel: input: Nintendo Co., Ltd. Pro Controller as /devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2/1-2:1.0/0003:057E:2009.000A/input/input33
Apr 27 03:05:30 hostname kernel: hid-generic 0003:057E:2009.000A: input,hidraw8: USB HID v1.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:05:00.3-2/input0
Apr 27 03:05:30 hostname mtp-probe[7708]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 27 03:05:30 hostname mtp-probe[7708]: bus: 1, device: 5 was not an MTP device
Apr 27 03:05:30 hostname mtp-probe[7722]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 27 03:05:30 hostname mtp-probe[7722]: bus: 1, device: 5 was not an MTP device
Apr 27 03:05:31 hostname polkitd[653]: Error converting subject to JS object: Process 7731 terminated
Apr 27 03:05:31 hostname polkitd[653]: Error converting subject to JS object: Process 7735 terminated
Apr 27 03:05:31 hostname kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input34
Apr 27 03:05:34 hostname kernel: usb 1-2: USB disconnect, device number 5

I mainly play with controller, so it has been very frustrating to have it be unusable and not know why or how to fix it. Any help is appreciated.

I’ve had all sorts of issues with my xbox elite controller. Including this issue.

I got like a $20 usb dongle made by 8bitdo off Amazon and everything has gone away. I have no idea what magic they did, but it’s probably the best $20 I’ve ever spent.

Did you do anything in particular to get it to work via the dongle? I’ve purchased the 8BitDo Wireless Adapter 2 and I’m experiencing what appears to be the same issue when connecting over the dongle in Switch Pro mode, except that Steam won’t even detect it as connected for the brief moment it is connected. (Steam also won’t detect it when connecting directly to my laptop over bluetooth, which I have tried.) I can’t even get the adapter to pair in xinput mode (likely because the Gulikit controller is spoofing an Xbox 360 controller, [as the 360 controller has the exact same buttons as a modern Xbox controller], while the 8BitDo Wireless Adapter 2 only advertises support for One and Series controllers).

I’ve put the journal for the event below, in case it helps.

Journal of what happens when I try to connect via the dongle
Apr 30 14:31:18 hostname kernel: usb 1-2: new full-speed USB device number 9 using xhci_hcd
Apr 30 14:31:18 hostname kernel: usb 1-2: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.00
Apr 30 14:31:18 hostname kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 30 14:31:18 hostname kernel: usb 1-2: Product: 8BitDo Receiver
Apr 30 14:31:18 hostname kernel: usb 1-2: Manufacturer: 8BitDo
Apr 30 14:31:18 hostname kernel: usb 1-2: SerialNumber: E417D8EF72B8
Apr 30 14:31:18 hostname mtp-probe[14417]: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:18 hostname mtp-probe[14417]: bus: 1, device: 9 was not an MTP device
Apr 30 14:31:18 hostname kernel: input: 8BitDo Pro 2 Wired Controller as /devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2/1-2:1.0/input/input31
Apr 30 14:31:18 hostname kernel: usbcore: registered new interface driver xpad
Apr 30 14:31:18 hostname mtp-probe[14420]: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:18 hostname mtp-probe[14420]: bus: 1, device: 9 was not an MTP device
Apr 30 14:31:18 hostname kernel: usb 1-2: USB disconnect, device number 9
Apr 30 14:31:18 hostname kernel: xpad 1-2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
Apr 30 14:31:18 hostname (udev-worker)[14416]: xpad0: Process 'qtile udev --group wheel backlight --device xpad0' failed with exit code 1.
Apr 30 14:31:18 hostname kernel: usb 1-2: new full-speed USB device number 10 using xhci_hcd
Apr 30 14:31:18 hostname kernel: usb 1-2: New USB device found, idVendor=2dc8, idProduct=3107, bcdDevice= 2.00
Apr 30 14:31:18 hostname kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 30 14:31:18 hostname kernel: usb 1-2: Product: IDLE
Apr 30 14:31:18 hostname kernel: usb 1-2: Manufacturer: 8BitDo
Apr 30 14:31:18 hostname kernel: usb 1-2: SerialNumber: E417D8EF72B8
Apr 30 14:31:19 hostname kernel: hid-generic 0003:2DC8:3107.000F: hiddev96,hidraw1: USB HID v1.10 Device [8BitDo IDLE] on usb-0000:05:00.3-2/input0
Apr 30 14:31:19 hostname mtp-probe[14447]: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:19 hostname mtp-probe[14447]: bus: 1, device: 10 was not an MTP device
Apr 30 14:31:19 hostname mtp-probe[14449]: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:19 hostname mtp-probe[14449]: bus: 1, device: 10 was not an MTP device
Apr 30 14:31:20 hostname kernel: usb 1-2: USB disconnect, device number 10
Apr 30 14:31:20 hostname kernel: usb 1-2: new full-speed USB device number 11 using xhci_hcd
Apr 30 14:31:20 hostname kernel: usb 1-2: New USB device found, idVendor=2dc8, idProduct=3107, bcdDevice= 2.00
Apr 30 14:31:20 hostname kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 30 14:31:20 hostname kernel: usb 1-2: Product: IDLE
Apr 30 14:31:20 hostname kernel: usb 1-2: Manufacturer: 8BitDo
Apr 30 14:31:20 hostname kernel: usb 1-2: SerialNumber: E417D8EF72B8
Apr 30 14:31:20 hostname kernel: hid-generic 0003:2DC8:3107.0010: hiddev96,hidraw1: USB HID v1.10 Device [8BitDo IDLE] on usb-0000:05:00.3-2/input0
Apr 30 14:31:20 hostname mtp-probe[14515]: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:20 hostname mtp-probe[14515]: bus: 1, device: 11 was not an MTP device
Apr 30 14:31:20 hostname mtp-probe[14517]: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb1/1-2"
Apr 30 14:31:20 hostname mtp-probe[14517]: bus: 1, device: 11 was not an MTP device
Apr 30 14:31:28 hostname kernel: usb 1-2: USB disconnect, device number 11

Nope. Didn’t do anything but connect to it. It works great.

Further analysis of the issue (using watch -dn1 lsusb) seems to suggest it may be a hardware issue with the controller. Looking into this further; will report results

It was indeed a hardware issue. Buying a new cable fixed it.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.