Kodi v19.1 update - lost gamepad support

Help and Support Vero 4K / Vero 4K +
1

Hi,

All in all the Kodi v19.1 upgrade went just fine - so far… Now I just noticed that my two wireless gamepads (using USB/2.4 GHz tranceivers) don’t work anymore.

.kodi/temp/kodi.log shows that the driver is being loaded:

INFO <general>: CAddonMgr::FindAddons: peripheral.joystick v1.7.2 installed
[...]
INFO <general>: AddOnLog: peripheral.joystick: Enabling joystick interface "linux"

I also tried the udev driver but to no avail.
I can see that the USB device is found during boot (or on connect after boot):

usb 1-1.2: new full-speed USB device number 10 using xhci-hcd
usb 1-1.2: New USB device found, idVendor=2563, idProduct=0575
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: USB WirelessGamepad
usb 1-1.2: Manufacturer: ShanWan

However, the first curiosity I noticed is that without manual disconnect/reconnect the USB device found doesn’t lead to an input device being created. Only when done manually sysfs apparently registers a new input device:

input: ShanWan USB WirelessGamepad  as /devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/0003:2563:0575.0008/input/input10
hid-generic 0003:2563:0575.0008: input,hidraw0: USB HID v1.10 Gamepad [ShanWan USB WirelessGamepad ] on usb-xhci-hcd.0.auto-1.2/input0

Unfortunately, devfs still doesn’t. There used to be a device like /dev/input/js0 which could be tested using jstest for example. After the upgrade there’s no such device anymore…

Any idea?

Thanks

2

Hi @brevilo

Unfortunately I don’t have this dongle, so all I can suggest is installing a version of OSMC where it worked and then running

lsmod | paste-log and sending me the output.

This should let me work out if something is missing from our 4.9 kernel

Cheers

Sam

3

Hey Sam,

thanks for the quick reply (as always). Before I go down that route, I quickly checked things on a PC’s Debian Buster with kernel 4.19. The only extra module loaded on connect is joydev and the devfs node is being created as usual while the dmesg output is similar to that above.

I checked /boot/config-4.9.113-45-osmc and confirmed CONFIG_INPUT_JOYDEV=y. So joydev is compiled in and thus won’t appear in the output of lsmod. I checked the joystick-specific stock kernel options in Debian Buster and there’s nothing compiled in, only modules (besides module-specific options), so the lsmod check above should be complete:

# grep -e "CONFIG.*JOYSTICK" /boot/config-4.19.0-17-amd64
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_ZHENHUA=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
# CONFIG_JOYSTICK_AS5011 is not set
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_JOYSTICK_XPAD=m
CONFIG_JOYSTICK_XPAD_FF=y
CONFIG_JOYSTICK_XPAD_LEDS=y
CONFIG_JOYSTICK_WALKERA0701=m
# CONFIG_JOYSTICK_PSXPAD_SPI is not set
CONFIG_JOYSTICK_PXRC=m

I think I’ll check a Raspian Buster next…

4

Same behavior as seen with the PC’s Debian Buster (all working as expected).

Does the above help by any means…?

5

If you can remind me about this in a couple of weeks I can take a closer look.

6

Sure! Added to my calendar :smirk:

7

You wanted me to remind you @sam_nazarko. So, there you go :innocent:

Cheers

8

Thanks. I’ll take a look shortly.

9

Hi @sam_nazarko, a quick update: the OSMC November release (with Kodi 19.3) did not improve things in this context, unfortunately. Still no /dev/input/jsX device.

Cheers

10

Understood. Unfortunately it wasn’t clear to me which kernel module is missing / needs adding. If we can ascertain that I can gladly get it in the next release.

11

tl;dr: can you please set CONFIG_HID_BETOP_FF?

Hi Sam, I thought with the latest OSMC release (no change) it was about time to pick this up again. Looking again at how the device presents itself I noticed the following:

[512732.923906] usb 1-1.1: new full-speed USB device number 10 using xhci-hcd
[512733.057267] usb 1-1.1: New USB device found, idVendor=2563, idProduct=0575
[512733.057276] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[512733.057281] usb 1-1.1: Product: USB WirelessGamepad
[512733.057284] usb 1-1.1: Manufacturer: ShanWan
[512733.081809] input: ShanWan USB WirelessGamepad  as /devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:2563:0575.0008/input/input10
[512733.084974] hid-generic 0003:2563:0575.0008: input,hidraw0: USB HID v1.10 Gamepad [ShanWan USB WirelessGamepad ] on usb-xhci-hcd.0.auto-1.1/input0
[512733.143632] usb 1-1.1: USB disconnect, device number 10
[512733.783869] usb 1-1.1: new full-speed USB device number 11 using xhci-hcd
[512733.916536] usb 1-1.1: New USB device found, idVendor=20bc, idProduct=5500
[512733.916544] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[512733.916549] usb 1-1.1: Product: USB WirelessGamepad
[512733.916552] usb 1-1.1: Manufacturer: ShanWan

Curiously, it seems to reconnect itself under different vendor/product IDs after the initial registration. Looking through the kernel sources it turns out that there is direct HID support for this device as of Linux 4.0. Looking further at the Vero4K kernel config changes from 3.x to 4.x one can see that the option CONFIG_HID_BETOP_FF isn’t set. It might be as easy as enabling that.

While this doesn’t really explain how things worked prior Kodi 19 (Linux 3.x?), it hopefully gives you a better idea on what to home in on.

Update 1: I couldn’t verify the idea on a stock Debian Buster (amd64) because the device doesn’t reconnect/re-identify there. It just stops at the input/hid-generic registration step in the log above.

Update 2: The reconnect/re-identify does not happen (visibly in dmesg) on a normal boot with the device plugged into the Vero 4K. In that case idVendor=20bc, idProduct=5500 is registered right away.

Also, this device has yet another mode where it mimics a XBOX 360 controller (idVendor=045e, idProduct=028e) but that mode apparently needs to be switched to manually, which is seemingly possible when connected to a PC (architecture?) only, by pressing the MODE button for 5 secs.

For the record: it appears to boil down to this:

  • Vero4K (aarch/arm):
    • Android BFM mode: idVendor=20bc, idProduct=5500 → CONFIG_HID_BETOP_FF required
  • PC (amd64) [alternate via MODE button]:
    • PS3 mode: idVendor=2563, idProduct=0575 → no idea how to enable/support that
    • XBOX 360 mode: idVendor=045e, idProduct=028e → use xpad or xboxdrv

Thanks!

12

Hey @sam_nazarko, just pinging you in case you’re not being notified on reply:

Could you please try setting CONFIG_HID_BETOP_FF? I reckon it should fix the issue (see previous post for details).

Cheers!

13

I’ve seen this and did make a note, but I’m unable to make changes available via APT at this time while we move to Bullseye and a new video stack.

This can go in after Bullseye and our next video stack.

If you are interested in a test build, let me know.

14

Ok, Sam. Sorry for bugging you twice then. This can certainly wait until the bullseye upgrade. Maybe consider adding it as a module from the get go? I’ll contact you about the test build…

Cheers

15

Testing the beta yields:

[  479.442833] usb 1-1.1: new full-speed USB device number 8 using xhci-hcd
[  479.574519] usb 1-1.1: New USB device found, idVendor=2563, idProduct=0575
[  479.574528] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  479.574532] usb 1-1.1: Product: USB WirelessGamepad
[  479.574536] usb 1-1.1: Manufacturer: ShanWan
[  479.599596] input: ShanWan USB WirelessGamepad  as /devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:2563:0575.0003/input/input10
[  479.600028] hid-generic 0003:2563:0575.0003: input,hidraw2: USB HID v1.10 Gamepad [ShanWan USB WirelessGamepad ] on usb-xhci-hcd.0.auto-1.1/input0
[  479.661363] usb 1-1.1: USB disconnect, device number 8
[  480.352809] usb 1-1.1: new full-speed USB device number 9 using xhci-hcd
[  480.484823] usb 1-1.1: New USB device found, idVendor=20bc, idProduct=5500
[  480.484877] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  480.484882] usb 1-1.1: Product: USB WirelessGamepad
[  480.484885] usb 1-1.1: Manufacturer: ShanWan
[  480.495708] input: ShanWan USB WirelessGamepad  as /devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:20BC:5500.0004/input/input11
[  480.497051] betop 0003:20BC:5500.0004: input,hidraw2: USB HID v1.11 Gamepad [ShanWan USB WirelessGamepad ] on usb-xhci-hcd.0.auto-1.1/input0
[  480.497089] betop 0003:20BC:5500.0004: Force feedback for betop devices by huangbo <huangbobupt@163.com>
[  480.500059] input: ShanWan USB WirelessGamepad  as /devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1:1.1/0003:20BC:5500.0005/input/input12
[  480.563196] betop 0003:20BC:5500.0005: input,hidraw3: USB HID v1.11 Device [ShanWan USB WirelessGamepad ] on usb-xhci-hcd.0.auto-1.1/input1
[  480.563204] betop 0003:20BC:5500.0005: no output reports found

Apparently, that’s indeed enough as I could verify two pads working just fine in parallel using jstest (via /dev/input/js0 and /dev/input/js1).

OSMC also detected the new controller(s) and offered to configure them in the settings. I didn’t follow through as CEC seemed to be disabled and I couldn’t control the UI I did configure a Kodi controller and it worked flawlessly. Problem solved, I reckon :smirk:

Finally!

1 Like
16

Great!