X-input devices seem to be limited to 3

So, I’ve found a bug in the N2 builds of CoreELEC. Including the latest nightly (5/24).

I’ve got four GameSir G3s controllers, and they connect via 2.4ghz dongle as an Xbox 360 compatible X-Input device. I’ve had two of them for over a year and they’ve been so good that I’ve bought two more so that I can ditch the two Shanwan Dualshock-III knockoffs that’ve never performed very well. I’ve used the two original G3s with the Dualshock controllers for a while on my C2 with little problem in both Kodi and sx05re, and then later when I got my N2.

But when I added the new G3s to the N2, I discovered that only three of them were ever seen by Kodi or sx05re (which I assume uses the same input backend). Which controller it was didn’t matter. This was tested by pulling two dongles; the “non-working” (I have them all colour coded) dongle plus another. I plug in the “non-working” one again, and it works fine. The 2nd pulled dongle then fails to work when plugged back in. The last in the chain always seems to fail.

So I’ve gone through the following troubleshooting in this order:

  1. Bumped up the power supply on the N2 to a 3.3a (from 2.5a), thinking maybe it was a power issue.
  2. Swapped out the powered USB hub they were attached to a beefier one.
  3. Tested all four dongles on my iMac simultaneously on the beefy powered hub
  4. Tested all four dongles on my Odroid C2 (running CE 9.0.2 stable) with the original hub.

All four worked on the iMac and the C2, and the USB hub swap didn’t make a difference on the N2.

Ruling out a stable version of CE tells me it’s either the CE nightlies, or the N2 itself (or a combination thereof).

Log: http://ix.io/1K1y

Any ideas?

Additionally…

lsusb shows the controller dongle attached:

KodiLivingRoom:~ # lsusb
Bus 002 Device 002: ID 05e3:0620 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 045e:028e Microsoft Corp. Xbox360 Controller
Bus 001 Device 011: ID 045e:028e Microsoft Corp. Xbox360 Controller
Bus 001 Device 012: ID 045e:028e Microsoft Corp. Xbox360 Controller
Bus 001 Device 010: ID 045e:028e Microsoft Corp. Xbox360 Controller
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

But evtest doesn’t see it:

KodiLivingRoom:~ # evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: cec_input
/dev/input/event1: meson-ir
/dev/input/event2: XiaoMi RC
/dev/input/event3: Microsoft X-Box 360 pad
/dev/input/event4: Microsoft X-Box 360 pad
/dev/input/event5: Microsoft X-Box 360 pad
Select the device event number [0-5]:

Additionally, checking dmesg for USB shows a stupid error that seems to be limited to USB3.

KodiLivingRoom:~ # dmesg | grep -i USB
[ 0.465365@2] usbcore: registered new interface driver usbfs
[ 0.465400@2] usbcore: registered new interface driver hub
[ 0.465473@2] usbcore: registered new device driver usb
[ 0.550668@2] ehci_hcd: USB 2.0 ‘Enhanced’ Host Controller (EHCI) Driver
[ 0.550671@2] ohci_hcd: USB 1.1 ‘Open’ Host Controller (OHCI) Driver
[ 0.550966@2] usbcore: registered new interface driver cdc_acm
[ 0.550969@2] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 0.551003@2] usbcore: registered new interface driver usb-storage
[ 0.551066@2] usbcore: registered new interface driver usbserial
[ 0.551093@2] usbcore: registered new interface driver usbserial_generic
[ 0.551116@2] usbserial: USB Serial support registered for generic
[ 0.551528@2] usbcore: registered new interface driver xpad
[ 0.553194@2] usbcore: registered new interface driver usbhid
[ 0.553196@2] usbhid: USB HID core driver
[ 0.611690@2] amlogic-new-usb2-v2 ffe09000.usb2phy: USB2 phy probe:phy_mem:0xffe09000, iomap phy_base:0xffffff80084f5000
[ 0.611832@2] amlogic-new-usb3-v2 ffe09080.usb3phy: USB3 phy probe:phy_mem:0xffe09080, iomap phy_base:0xffffff80084fd080
[ 1.496407@2] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 1.497083@2] hub 1-0:1.0: USB hub found
[ 1.497221@2] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 1.497246@2] usb usb2: We don’t know the algorithms for LPM for this host, disabling LPM.
[ 1.497446@2] hub 2-0:1.0: USB hub found
[ 1.735273@3] dwc_otg: usb0: type: 2 speed: 0, config: 0, dma: 0, id: 0, phy: ffe09000, ctrl: 0
[ 1.762859@2] amlogic-new-usb2-v2 ffe09000.usb2phy: —Set port(0) tuning for host cf(xhci_hub_control)–
[ 1.822839@2] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 1.977474@2] hub 1-1:1.0: USB hub found
[ 2.086964@2] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 2.121450@2] hub 2-1:1.0: USB hub found
[ 2.322855@2] usb 1-1.2: new full-speed USB device number 3 using xhci-hcd
[ 2.457388@2] usb 1-1.2: Unsupported device
[ 2.457483@2] usb 1-1.2: Unsupported device
[ 2.457564@2] usb 1-1.2: Unsupported device
[ 2.457634@2] usb 1-1.2: Unsupported device
[ 2.558839@2] usb 1-1.4: new high-speed USB device number 4 using xhci-hcd
[ 2.713492@2] hub 1-1.4:1.0: USB hub found
[ 3.002839@2] usb 1-1.4.1: new full-speed USB device number 5 using xhci-hcd
[ 3.129650@2] input: Microsoft X-Box 360 pad as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/input/input1
[ 3.129981@2] usb 1-1.4.1: Unsupported device
[ 3.130105@2] usb 1-1.4.1: Unsupported device
[ 3.130912@2] usb 1-1.4.1: Unsupported device
[ 3.214835@2] usb 1-1.4.2: new full-speed USB device number 6 using xhci-hcd
[ 3.321502@2] input: Microsoft X-Box 360 pad as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.0/input/input2
[ 3.321768@2] usb 1-1.4.2: Unsupported device
[ 3.321878@2] usb 1-1.4.2: Unsupported device
[ 3.322783@2] usb 1-1.4.2: Unsupported device
[ 3.402838@2] usb 1-1.4.3: new full-speed USB device number 7 using xhci-hcd
[ 3.513513@2] input: Microsoft X-Box 360 pad as /devices/platform/ff500000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/input/input3
[ 3.513738@2] usb 1-1.4.3: Unsupported device
[ 3.513890@2] usb 1-1.4.3: Unsupported device
[ 3.514906@2] usb 1-1.4.3: Unsupported device
[ 3.598885@2] usb 1-1.4.4: new full-speed USB device number 8 using xhci-hcd
> [ 3.707667@2] usb 1-1.4.4: Not enough host controller resources for new device state.
> [ 3.707680@2] usb 1-1.4.4: can’t set config #1, error -12
[ 4.757149@0] usbcore: registered new interface driver btusb

More info about this error here: debian - Not enough host controller resources for new device state - Super User

Looks like this is a USB3 limitation.

Yeah through xhci, but why is this happening? Power or number of addresses doesn’t seem to be an issue. I haven’t seen USB choke on such a fairly acceptable number of devices (5) and it’s doubtful I’ll be the only one to encounter this problem over the longterm. Is it possible to work in a switch to disable xhci in favour of ehci/USB 2.0 for those who don’t need the extra throughput? 4 controller dongles and a BT USB used for a remote control won’t push close to 480Mbps, let alone 5000.

That said, in lieu of hope that a software fix can be found, I’m gonna try running one of the dongles through an adapter on the microUSB port. That should work, no?

Do you actually need to have one dongle for each device? I have no experience with these particular controllers but a lot of other similar devices it is possible to pair multiple controllers to a single dongle.

Yep, in all my testing, that is the case. 1 dongle per. No indication anywhere on the website or documentation otherwise. Documentation is scarce, regardless, as undocumented commands have occasionally come to light on Reddit.

As for why one dongle per, my assumption is this is because they will also function wired, and I suspect the dongle was more an afterthought to the G3w (the wired-only version), and it’s just a bridge to the USB on-board the gamepad.

They will also work over BT, but I prefer not using them that way, as the latency in Bluetooth in other SBCs (Pi, C2) has always been noticeable to me. I also live in a building with a lot of BT interference. It’s fine for a remote control, but leads to problems with gaming.

I will dig out four micro USB cables and get back to you as to whether they all function wired, but I have a sneaking suspicion it’ll be the same issue. Which would be frustrating, given the wired version of this controller seems to be sold on HK’s own website.

I don’t know if it’s a hw limitation or something we can change. Every Hub counts as device. Also there is already a hub onboard to have those 4 ports.

No idea about G3 in other systems setting controller for direct input mode rather than x-input allows multiple controllers to be paired to single dongle.

Yep, same results going with wired, as I figured (ruling out any 2.4ghz/USB3 shenanigans like what’s being posted about in the N2 Test Build thread). Presumably, the same happens with the G3w.

[ 5276.479841@2] usb 1-1.4.4: new full-speed USB device number 16 using xhci-hcd
[ 5276.592055@2] usb 1-1.4.4: Not enough host controller resources for new device state.
[ 5276.592072@2] usb 1-1.4.4: can’t set config #1, error -12

I can’t find any documentation on how to enable direct input, even though it’s listed as “supported” on the GameSir site and others. I suspect it’s just a default if Xinput drivers aren’t present.

Regardless, there doesn’t seem to be a way to pair multiple controllers on one dongle. None that I’ve found anyhow. I’ve joined the gamesir official Facebook page in hopes of finding some answers there, but the subscription is still pending.

Is that the micro otg port? This one is USB2 so there shouldn’t be a problem.

Not yet. Waiting for a microUSB adapter that should be coming tomorrow.

That said, my hopes are not high as at least according to dmesg, it looks like all ports are xhci, and from all appearances, people with the same error keep pointing towards xhci. Disabling xhci seems to work for PCs (where a bios setting can downgrade USB3 ports to ehci/USB2), but otherwise it’s something that has to be built into the kernel.

We can tweak the kernel config. I have to admit I never seen this issue and I haven’t researched or looked into it yet. But I promise to look into it. I also pinged HK developer tobetter to hear if it is a real hardware limitation or not. I think we will be able to workaround or fix this somehow.

I appreciate any help. I also made a post onto the Odroid.com N2 forum about the issue as well.

It just seems like such an odd thing. Including the powered hub, I’m running 6 USB devices total, which was more than doable on machines 20 years ago let alone in 2019.

127-devices-unless-they-happen-to-be-Xbox-360-controllers… :confused:

From instructions Direct Input mode should be selected via A + Home. https://gamesir.hk/pages/g3s-tutorial

That’s my bad (combined with poor documentation) not knowing that “android mode” means “obsolete proprietary Windows input API”. Even running them in “android mode”, it’s still only one controller per dongle. They would appear to be hard-paired; I cannot get a dongle to see its non-original controller.

I can get all four going if one dongle is running DInput, which just adds to the frustration as to why XInput is limited.

It also means that controller is now without vibration.

As this appears to be a wider N2 problem (it’s happening on Ubuntu as well), a thread about this now exists on the Odroid forums:

https://forum.odroid.com/viewtopic.php?f=180&t=35191

Is there a way for me to reproduce? With 5 usb hdd’s or something?

I’m not sure. I don’t know that I could scrape together 5 free externals to test. I’ll test with Android today and post results to the Odroid forum. The more I look though around the internet, the more it seems like it’s an issue with xhci, but I want to try ruling out as many things as possible. That said, if it’s xhci, would there be a way to limit the USB 2.0 OTG port to echi-only? It doesn’t benefit from a USB 3 controller driver anyway. It wouldn’t be a fix per se, but would be a satisfactory workaround.