xone: Liquid Metal/ PowerA Controller No Input

[dcrdev]

I'm trying to get a third party controller working.

So I've cloned the repo and built the dkms module and the controller is showing up as an interface under /dev/input/js0 - however I'm getting no input from the controller whatsoever.

Running the jstest utility brings up some info - but appears to be entirely unresponsive to any buttons pressed on the pad.

Looking at the source code, in particular xpad.c the controller should be support by vendorid and productid { 0x24c6, 0x543a, "PowerA Xbox One wired controller", 0, XTYPE_XBOXONE },

Can anyone help?

[FeralBytes]

Same Issue.

[paroj]

can you try again with latest master?

[FeralBytes]

@paroj I did use the latest master 2 days ago. But unfortunately; I was upset by broken MS crap. SO I took them back and got 2 steam controllers today before I saw this comment. Sorry otherwise I would have pulled it down again and tested the changes.

[paroj]

the last 3 commits on Sep 3, 2016 improve xpad one support. The issue probably is a new firmware on the controllers which needs the updated handling that was implemented in the last commits.

[nderr]

I'm encountering this same issue (the controller is recognized, but no input is detected.) I also have an earlier Power A Xbox One controller lying around which does work. I'm attaching the output of dmesg and lsusb for both.

Long story short, the two controllers have the same vendor and product ID (24c6 and 543a), but different names ("XBox ONE Pro Ex controller" works, while "XBox ONE liquid metal controller" does not) and different endpoint addresses - {[1 out, 1 in]; [8 out, 7 in]; [3 out, 3 in]} for the working controller and {[2 out, 1 in]; [4 out, 3 in]; [6 out, 5 in]} for the non-working liquid metal controller.

I'm not familiar with the ins and outs of USB device management, but it looks as though xpad categorizes the controllers based solely on the product/vendor ID and miscategorizes the liquid metal controller. Is that accurate?

dmesg_liq_met.txt dmesg_pro_ex.txt lsusb_liq_met.txt lsusb_pro_ex.txt

[paroj]

this is the part where the endpoints are picked: https://github.com/paroj/xpad/blob/master/xpad.c#L1566-L1582

maybe @cgutman can provide more hints.

[paroj]

can you try again with current master? A second init packet was added which fixed some other third party pads.

[cgutman]

@paroj I think the endpoint selection code is definitely suboptimal but doesn't seem to have caused real problems yet (possibly by luck). The code depends on OUT endpoint being placed before the IN endpoint in the interface descriptor for all Xbox One controllers.

We know at least one controller that breaks this rule, that's the Titanfall 2 controller. Fortunately, because it uses endpoint addresses 0x81 and 0x01, the code works because the USB core masks off the 0x80 direction flag when processing the endpoint address anyway.

If a hypothetical controller had both:

• endpoint addresses that were not equal when masked by 0xF - like the Liquid Metal controller
• swapped order of IN and OUT endpoints - like the Titanfall 2 controller

Then it wouldn't work, but we don't know whether any such controller really exists. It's probably worth fixing anyway.

[nderr]

Thanks for looking at this! Using the current master gives the same results (i.e. the liquid metal pad is still unresponsive.)

[cgutman]

@nderr Can you try with this xpad.c? http://pastebin.com/raw/Re8xby26

[nderr]

@cgutman Tried it - still no luck.

[cgutman]

@nderr thanks for testing. Is this the controller model that isn't working? https://www.amazon.com/Official-Licnesed-Wired-Liquid-Metal-Controller/dp/B0179K5L98

[nderr]

@cgutman It's this one: https://www.amazon.com/POWER-WIRED-CONTROLLER-XBOX-ONE-GREEN/dp/B01KTKHVC0

Although, as noted above, the product string in a call to dmesg identifies it as a liquid metal controller.

[Trevdish30]

Same problem with the same controller.

[cgutman]

@nderr @Trevdish30 If either of you have a Windows machine accessible, please try getting us a packet capture of the official driver - https://franticrain.github.io/sniffing/index.html

[Trevdish30]

xbox one.txt

I have no idea if this is right but this is what I got.

[cgutman]

@Trevdish30 Can you try uploading it as a pcap file? I think uploading it as a txt file may have messed up the capture because Wireshark won't open it.

[nderr]

I tried doing it as well. xone_liquid_metal.zip

[Trevdish30]

It tells me the pcap file is empty when i try uploading it.

[cgutman]

Please test the "powera" branch of my repo. https://github.com/cgutman/xpad/tree/powera

[cgutman]

@nderr @Trevdish30 I'm preparing a patch upstream to fix the PowerA gamepads. Can you try my "for_upstream" branch? https://github.com/cgutman/xpad

If that works, may I add a "Tested-By: Firstname Lastname Email address" from you for my submission upstream?

[MDCore]

@cgutman just tried your powera branch and it works for me now on jstest and steam!

[nderr]

Sorry for the delay - I had no access to the pad until today. I've tested the for_upstream branch with jstest-gtk and everything appears to work perfectly!

[ghost]

@cgutman I can also confirm that your branch works with the PowerA gamepad, thanks so much for your work!

[Trevdish30]

I am still getting no input on jstest or steam with the patch. could someone tell me what exactly what to do or how they go it to work so I know if I am just not doing it right or if it just doesn't work.

[MDCore]

@Trevdish30 this is what I did, roughly, on two separate machines. I'm only 80% sure about this, it has been a few weeks. I based my instructions off of the README here: https://github.com/paroj/xpad/ and off my bash history :)

Edit: See https://github.com/paroj/xpad/issues/48#issuecomment-287226479 below for accurate instructions

[Trevdish30]

@MDCore Thank you for your response but I am still not getting an input from the controller.

[ghost]

@Trevdish30 I just checked my history and here's what I did (as root). Note the added rmmod xpad

cd /usr/src
git clone https://github.com/cgutman/xpad xpad-0.4-powera
cd xpad-0.4-powera
git checkout powera
rmmod xpad
sudo dkms remove -m xpad -v 0.4 --all
sudo dkms install -m xpad -v 0.4-powera
modprobe xpad

You should see a DKMS: uninstall completed. near the end of the output from the dkms remove command and a DKMS: install completed. at the end of the dkms install command

[paco3346]

@cgutman Just dropping by to give my thumbs up to the powera branch as well. Works swimmingly!

Arch 4.10.8-1 with Steam (native runtime).

[cgutman]

I made some changes to the PowerA patch per the upstream input subsystem maintainer's request. It now only sends the special quirk initialization packets to known buggy gamepad. This change is queued for inclusion in kernel 4.12.

I included all known quirky gamepads from this bug report, other reports on this repo, and Valve's list in their Steam Link kernel source.

The upstream change is in my for_upstream branch. If there are more PowerA gamepads that don't work and aren't on the quirk list, we'll need to add them.

The list of gamepads using the PowerA quirk is currently: 0x24c6:0x541a 0x24c6:0x542a 0x24c6:0x543a

If your gamepad needs the quirk and doesn't have it (i.e. only works using the powera branch, not the for_upstream branch), file a ticket and we can send that upstream.