[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-input
Subject:    8BitDo USB controller disconnect/reconnect loop
From:       Nikos Chantziaras <realnc () gmail ! com>
Date:       2024-01-13 17:02:58
Message-ID: unufo3$det$1 () ciao ! gmane ! io
[Download RAW message or body]

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?


[prev in list] [next in list] [prev in thread] [next in thread]