Hello.
Support for the 8BitDo Pro 2 Wired controller was added in kernel 6.3.
I'm currently using 6.6.11 (I use LTS kernels.)
When I connect the controller, it rumbles every few seconds. Looking at
dmesg, the reason is that it constantly disconnects and reconnects:
usb 1-4: new full-speed USB device number 6 using xhci_hcd
usb 1-4: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice=
1.14
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 8BitDo Pro 2 Wired Controller
usb 1-4: Manufacturer: 8BitDo
usb 1-4: SerialNumber: 817EC44BB302
input: 8BitDo Pro 2 Wired Controller as
/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-4/1-4:1.0/input/input13
input input13: unable to receive magic message: -121
usb 1-4: USB disconnect, device number 6
xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed
with result -19
usb 1-4: new full-speed USB device number 7 using xhci_hcd
usb 1-4: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice=
1.14
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 8BitDo Pro 2 Wired Controller
usb 1-4: Manufacturer: 8BitDo
usb 1-4: SerialNumber: 817EC44BB302
input: 8BitDo Pro 2 Wired Controller as
/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-4/1-4:1.0/input/input14
input input14: unable to receive magic message: -121
usb 1-4: USB disconnect, device number 7
xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed
with result -19
The index in /devices/ is also changing each time.
This goes on forever. It only stops happening when I launch an
application that uses the controller. Once I exit the application, this
behavior returns and it rumbles every 4 seconds or so.
Apparently this controller has a quirk where it needs to be polled once
in a while to keep it from disconnecting. I can't be sure why, but I
suspect it's because it tries to auto-detect the host system it's being
connected to. For example if it's connected to a PC, it switches to
X-Input mode. when it's connected to a Nintendo Switch, it switches to
that mode instead. But when it hasn't been polled for a few second, it
probably enters its auto-detection mode again.
While searching the web for this issue, I found other users with exactly
the same problem (I'm on Gentoo Linux, other users on Fedora and Arch
Linux.)
This behavior does not occur when using the controller in Microsoft
Windows 10. The controller's firmware is upgraded to the latest version
(1.03.)
Is there something I can do to fix this? Is there some kernel option or
perhaps a udev option I can use that would poll the controller once a
second or so to keep it alive?
