xpad return error -19 in the 8bitDo controller

[KonstantinDjairo]

https://pasteboard.co/zDQ2xRgvaVVI.png

output from dmesg after reboot i already tried to compile it again using dkms, but it doesn't change anything

the controller vibrates and the LED works, but it shuts itself down after 1s, i dont know why

[shadedmagus]

Can confirm. I have an 8bitdo Pro 2 Wired Controller and it disconnects and reconnects every 5 or so seconds. On every reconnect the controller rumbles for a split second.

It looks as though the system is recognizing the controller, so I'm not sure what is causing the constant disconnecting. I see no event in journalctl that explains the disconnect, but it instantly reconnects and increments the device ID in the bus.

journalctl output:

Oct 15 09:06:12 XXX kernel: usb 3-4: USB disconnect, device number 4
Oct 15 09:06:12 XXX kernel: xpad 3-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
Oct 15 09:06:12 XXX kernel: usb 3-4: new full-speed USB device number 5 using xhci_hcd
Oct 15 09:06:12 XXX kernel: usb 3-4: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice=1.14
Oct 15 09:06:12 XXX kernel: usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 15 09:06:12 XXX kernel: usb 3-4: Product: 8BitDo Pro 2 Wired Controller
Oct 15 09:06:12 XXX kernel: usb 3-4: Manufacturer: 8BitDo
Oct 15 09:06:12 XXX kernel: usb 3-4: SerialNumber: DE125C57B202
Oct 15 09:06:12 XXX kernel: input: 8BitDo Pro 2 Wired Controller as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:0a:00.3/usb3/3-4/3-4:1.0/input/input648
Oct 15 09:06:12 XXX mtp-probe[12855]: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:0a:00.3/usb3/3-4"
Oct 15 09:06:12 XXX mtp-probe[12855]: bus: 3, device: 5 was not an MTP device
Oct 15 09:06:12 XXX mtp-probe[12857]: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:0a:00.3/usb3/3-4"
Oct 15 09:06:12 XXX mtp-probe[12857]: bus: 3, device: 5 was not an MTP device

lsusb output:

Bus 003 Device 049: ID 2dc8:3106 8BitDo 8BitDo Pro 2 Wired Controller
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass          255 Vendor Specific Class
bDeviceSubClass       255 Vendor Specific Subclass
bDeviceProtocol       255 Vendor Specific Protocol
bMaxPacketSize0        64
idVendor           0x2dc8 8BitDo
idProduct          0x3106
bcdDevice            1.14
iManufacturer           1 8BitDo
iProduct                2 8BitDo Pro 2 Wired Controller
iSerial                 3 DE125C57B202
bNumConfigurations      1
Configuration Descriptor:
bLength                 9
bDescriptorType         2
wTotalLength       0x0030
bNumInterfaces          1
bConfigurationValue     1
iConfiguration          0
bmAttributes         0x80
(Bus Powered)
MaxPower              500mA
Interface Descriptor:
bLength                 9
bDescriptorType         4
bInterfaceNumber        0
bAlternateSetting       0
bNumEndpoints           2
bInterfaceClass       255 Vendor Specific Class
bInterfaceSubClass     93
bInterfaceProtocol      1
iInterface              0
** UNRECOGNIZED:  10 21 10 01 01 24 81 14 03 00 03 13 02 00 03 00
Endpoint Descriptor:
bLength                 7
bDescriptorType         5
bEndpointAddress     0x81  EP 1 IN
bmAttributes            3
Transfer Type            Interrupt
Synch Type               None
Usage Type               Data
wMaxPacketSize     0x0020  1x 32 bytes
bInterval               2
Endpoint Descriptor:
bLength                 7
bDescriptorType         5
bEndpointAddress     0x02  EP 2 OUT
bmAttributes            3
Transfer Type            Interrupt
Synch Type               None
Usage Type               Data
wMaxPacketSize     0x0020  1x 32 bytes
bInterval               4
Device Status:     0x0001
Self Powered

The only times the controller seems to stop disconnecting are as follows:

1. I invoke KDE System Settings > Input Devices > Controller. The controller stops disconnecting for the duration of this applet running. I can move to different sections in System Settings once the Controller applet has been invoked, and it will not disconnect again until I close System Settings completely.
2. I run jstest /dev/input/js0 - the controller will stop disconnecting until I kill jstest.

I have unplugged the controller and held the B button while plugging it in, but it doesn't make any difference.

From referencing errno-base.h it appears that error 19 is /* No such device */. (I think that applies here, not certain.)

[vwbusguy]

Oddly it doesn't happen for me as long as Steam is open, but as soon as I close Steam, it happens every 4-5 seconds, including a little rumble and this in journald over and over:

Feb 17 10:50:06 tirian kernel: usb 1-1: USB disconnect, device number 111
Feb 17 10:50:06 tirian kernel: xpad 1-1:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
Feb 17 10:50:06 tirian kernel: usb 1-1: new full-speed USB device number 112 using xhci_hcd
Feb 17 10:50:07 tirian kernel: usb 1-1: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
Feb 17 10:50:07 tirian kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 17 10:50:07 tirian kernel: usb 1-1: Product: 8BitDo Pro 2 Wired Controller
Feb 17 10:50:07 tirian kernel: usb 1-1: Manufacturer: 8BitDo
Feb 17 10:50:07 tirian kernel: usb 1-1: SerialNumber: 4A5C227C0D03
Feb 17 10:50:07 tirian kernel: input: 8BitDo Pro 2 Wired Controller as /devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb1/1-1/1-1:1.0/input/input132
Feb 17 10:50:07 tirian mtp-probe[182348]: checking bus 1, device 112: "/sys/devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb1/1-1"
Feb 17 10:50:07 tirian mtp-probe[182348]: bus: 1, device: 112 was not an MTP device
Feb 17 10:50:07 tirian kernel: input input132: unable to receive magic message: -121
Feb 17 10:50:07 tirian kernel: input input132: unable to receive magic message: -121
Feb 17 10:50:07 tirian mtp-probe[182350]: checking bus 1, device 112: "/sys/devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb1/1-1"
Feb 17 10:50:07 tirian mtp-probe[182350]: bus: 1, device: 112 was not an MTP device

Kernel: 6.7.4-200.fc39.x86_64

It's specific to the 8bitdo Pro 2, it seems. I also have a Logitech F310 plugged in and that one is not having the same issue.

[jschwartzenberg]

I have the same issue here. When the device is not used it keeps showing these disconnect messages. When it's used everything is ok. I bought this device in Action (NL), it has this on the bottom: Lab31 BV Westerblokker 32B 1695 AH Blokker The Netherlands

Model no.: LB-GA-GPV101-B Batcn no.: LB-18I Made in PRC

[sonic2kk]

Having the exact same issue, constantly seeing /dev/input/js1 appear and disappear as the controller turns on and off. Steam being opened or closed does not make a difference. There is a constant stream of xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19 errors when the controller turns on and off.

I am using Arch Linux with Linux Zen 6.9.2.

Testing wired and wireless on SteamOS works perfectly. I will try testing on some other devices as well.

EDIT: Confirmed on two other devices, one with Kubuntu 22.04 and one with Ubuntu 24.04, and the controller works out of the box on these devices. So this issue is specific to my Arch PC it seems..

[KonstantinDjairo]

what solved my issue was to blacklist the "hid-nintendo" from loading:

echo "blacklist hid-nintendo" | sudo tee /etc/modprobe.d/blocklist-hid-nintendo.conf && sudo update-initramfs -u

that command blacklists the hid-nintendo driver from loading and it generates a new initramfs. then reboot:

$ sudo reboot

please tell me if that solves your issue as well, i'll maintain that "issue" open because im not sure whether this solution works for other people or not.

[sonic2kk]

I will give this a try, although I am curious (and I am no expert so please tell me if I'm being silly):

Wouldn't this prevent a kernel-level driver for Nintendo Switch controllers (I use a Switch Pro Controller as well)? Also, does this mean hid-nintendo is intefering with the 8bitdo controller despite it being an Xbox-layout controller? There are Nintendo-layout variants I believe, so perhaps there is overlap here.

I understand Steam Input may still wrap the controller with its magic, but still curious :-)

[KonstantinDjairo]

I will give this a try, although I am curious (and I am no expert so please tell me if I'm being silly):

Wouldn't this prevent a kernel-level driver for Nintendo Switch controllers (I use a Switch Pro Controller as well)? Also, does this mean hid-nintendo is intefering with the 8bitdo controller despite it being an Xbox-layout controller? There are Nintendo-layout variants I believe, so perhaps there is overlap here.

I understand Steam Input may still wrap the controller with its magic, but still curious :-)

look, what xpad does is: it recognizes your controller and makes it be recognized as an xbox controller, so that you can play with no issue in most games/emulators (such as dolphin/cemu and so on)

so that "hid-nintendo" module is giving us a headache because it prevents xpad from turning your 8bitdo controller into a xbox one...

and yeah, i own a switch controller (joycon) and i can tell that this can cause a problem if you want to pair your joycons, because the driver for them is blacklisted (the hid-nintendo), but since you're using a 8bitdo controller, i assume you no longer need the joycons to play on the pc, right? also, i dont really think that there's any advantage of having the 8bitdo controller recognized as a switch controller in your computer... i think we should entrust this task to xpad, i've been using the 8bitdo ultimate bluetooth in 2.4ghz mode, with the dongle, and had no issue so far, and there's no delay

something that i would like, is to be able to use my switch joycons with xpad, without the need of relying on that "hid-nintendo" module which comes with the linux kernel... because i see no use of having it recognized as joycons instead of xbox controllers, as i mentioned earlier, literally makes them unusable =(

edit: it seems that blacklisting a driver only prevents it from loading at boot time, but you can still load it manually:

$ sudo modprobe hid-nintendo

that solves the issue~ now if you want it to be recognized as switch controller, just load the driver, or if you want to connect the joycons, i recommend that driver(which relies on hid-nintendo module) : https://github.com/DanielOgorchock/joycond

[sonic2kk]

and yeah, i own a switch controller (joycon) and i can tell that this can cause a problem if you want to pair your joycons, because the driver for them is blacklisted (the hid-nintendo), but since you're using a 8bitdo controller, i assume you no longer need the joycons to play on the pc, right?

That is unfortunate. I don't use my joycons on my PC, but I do use a Switch Pro controller. And I own many controllers, and I use them on my PC for local co-op occasionally. I'd like to still be able to use my Switch Pro Controller and my 8BitDo controller. I didn't buy my 8BitDo Ultimate as a replacement for any controller, but as an addition to the many controllers I already own.

So my ideal situation would be to be able to still use my 8BitDo and my Switch Pro controller, in particular I'd like to be able to use both at the same time. I do not want my 8BitDo to be recognised as a Switch Pro controller, I want it to be recognised as an Xbox Controller as it uses the Xbox layout.

Loading hid-nintendo after-the-fact is a good interim solution. This should also mean that doing sudo modprobe -r hid-nintendo to temporarily disable the driver should work as well. That means that for now, although I can't use my 8BitDo and Switch Pro controller at the same time, I can use one or the other by toggling the hid-nintendo driver I think.

I have not tested that but next time I pick up my controller to use on my PC (the controller and dongle are currently in my Steam Deck Dock) I'll see if this works.

---

Having said all this, it shouldn't be strictly necessary. On a machine with Ubuntu 24.04, and Kernel 6.5 iirc, I tested out my 8BitDo controller. It had I believe xpad and hid-nintendo loaded, and the 8BitDo Controller worked perfectly fine. So this issue is specific to my PC.

I have a laptop on the way that should be here in some weeks, and I'm planning to use Arch Linux on it as well, so I'll be interested to see if I run into any trouble with the controller there.

[KonstantinDjairo]

i tested in arch linux and i had to blacklist hid-nintendo there as well. i really think it's a issue regarding hid-nintendo and not specific to a single user