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?