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
So I have seen it work properly with
- Arch 6.1.3
: xinput mode
: ‘Plug and play’
The config where it isnt working is
- Coreelec 20
: xinput mode
: udev rules loading
I tried to edit the udev rules to start and bind hid_generic or hid_microsoft instead of xpadneo but I must be doing somethign wrong.
RUN:=“/bin/sh -c ‘echo hid_generic udev: $kernel > /dev/kmsg; modprobe hid_generic; echo $kernel > /sys/bus/hid/drivers/hid_generic/bind; echo hid_generic udev: ok > /dev/kmsg’”
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
I did some more digging around and there appear to be 2 kernel patches in play
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 :
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
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.
You will need a Amlogic-ne compatible device as it uses a 5.4 kernel.
Or custom build ng without the patch blocking hid_generic
Or use Switch mode which gets hid_generic under an unblocked deviceid