The more I dig into this, the weirder it gets. My hope was that it would fall back to some kind of plug and play loading of drivers If I took xpadneo out of the equation. I even tried just commenting out all the lines of the udev file
Here’s what happens when it loads hid_generic with plug and play on ubuntu
[ 188.710300] hid-generic 0005:045E:02E0.0003: unknown main item tag 0x0
[ 188.711702] input: 8BitDo Pro 2 as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:12/0005:045E:02E0.0003/input/input3
[ 188.713421] hid-generic 0005:045E:02E0.0003: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [8BitDo Pro 2] on 00:19:0e:17:56:de
and here’s what happens when I do try to load hid_generic with udev
[ 67.463838@1]- hid_generic udev: 0005:045E:02E0.0003
[ 67.469532@1]- hid_generic udev: ok
It acts like it is paired and loaded those drivers, but nothing registers
The first one basically looks like it explicitly prevents the kernel from doing what I was trying to get it to do… fall back onto hid_generic which I found to work on hardkernel’s ubuntu 4.9
The second just pulls xpadneo module into the kernel.
The device being stopped form using hid_generic is defined here
+#define USB_DEVICE_ID_MS_XBOX_ONE_S_2016 0x02e0
referencing what my 8bitdo pro 2 shows up as :
0005:045E:02E0
It also makes sense why when i switch it into nintendo switch mode it just loads hid_generic and works. The device identifier changes to
0005:057E:2009
Doing all this I noticed the xpadneo module version on corelec20 is very out of date, which rules out the previously linked github issue report being my issue, because that is caused by a commit 4 months ago. ( After loading the current xpadneo(v0.9-131) on my arch install I can confirm it still vibrates forever, but the vibration is greatly dampened and controller actually works in the background. The fail state with xpadneo on coreelec is extreme vibration forever with no working of any buttons, so it’s two similar but different issues.) Version 0.60 is hundreds of commits and 3 years old, and according to their github was never really supposed to work properly with kernel 4.9
Kernel 4.18 or newer required As of xpadneo v0.10, we require kernel 4.18 or later to utilize HID_QUIRK_INPUT_PER_APP which splits the gamepad into multiple sub-devices to fix problems and incompatibilities at several layers.
I think it’s just going to be easier for me to use the controller in nintendo switch mode with hid_generic, than to try to sort the xinput problems. Most of what seems to work well with xinput is reliant on newer kernels and versions of drivers. I do wonder if xboxone controllers are broken across the board on 20rc1 or if is just the 8bitdopro xboxone controller mode.
Sorry to blow up the forums, I did a lot of tinkering today.