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.

[kyleabeauchamp]

Is anyone still having issues after trying out the powera and for_upstream branches with unit 0x24c6:0x543a? I'm on Ubuntu 16.04 and still having difficulties, although user error is always a possibility :)

[kyleabeauchamp]

I should clarify: my controller is detected by jstest, but does not respond to any button presses.

I can see the device code in lsusb, but the device name is missing:

lsusb |grep 24c
Bus 001 Device 007: ID 24c6:543a  

The correct device name does appear in dmesg, however ([37421.825854] input: PowerA Xbox One wired controller as /devices/pci0).

Also: I can confirm (via modinfo) that I'm running the patched xmod.

I also wonder if this other patch is possibly necessary: https://gist.github.com/benbancroft/2a5d9bca700c29615f4d

For kicks, I also tried dropping in the steamos xpad.c and the Torvalds xpad.c, same behavior.

I've also tried fiddling with the udev permissions, but I don't know if that is even related

[cgutman]

@kyleabeauchamp I pushed a new branch for testing based on the new init packet I found in the gist you linked. Please try my powera_test branch.

[kyleabeauchamp]

Thanks @cgutman, I tried your latest branch with no luck.

I also tried adding an extra device name to the latest fork of xboxdrv (https://github.com/zerojay/xboxdrv/blob/97a173bba336acc1392dcbbcb4d7e54cde32d5b3/src/xpad_device.cpp#L148) and ended up in the same spot--the (userspace) driver detected the gamepad, but

I'll do some more debugging, as it's also possible that my gamepad has some sort of defect.

edit I found a nice guide to packet sniffing, in case I somehow gain access to a windows box: https://github.com/360Controller/360Controller/issues/312 https://franticrain.github.io/sniffing/index.html

[cgutman]

@kyleabeauchamp Can you reboot your PC without the gamepad attached, then attach the gamepad, and post the dmesg log of the attachment process?

[kyleabeauchamp]

[   77.922099] usb 1-1.5: new full-speed USB device number 5 using ehci-pci
[   78.017179] usb 1-1.5: New USB device found, idVendor=24c6, idProduct=543a
[   78.017184] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   78.017186] usb 1-1.5: Product: Xbox ONE liquid metal controller
[   78.017188] usb 1-1.5: Manufacturer: PowerA
[   78.017190] usb 1-1.5: SerialNumber: 00009EB5014EE6CA

[kyleabeauchamp]

That was without xpad. If I unplug, sudo modprobe xpad, then re-plug, I get:

[  129.586550] usbcore: registered new interface driver xpad
[  134.753104] usb 1-1.5: new full-speed USB device number 6 using ehci-pci
[  134.847723] usb 1-1.5: New USB device found, idVendor=24c6, idProduct=543a
[  134.847728] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  134.847731] usb 1-1.5: Product: Xbox ONE liquid metal controller
[  134.847733] usb 1-1.5: Manufacturer: PowerA
[  134.847735] usb 1-1.5: SerialNumber: 00009EB5014EE6CA
[  134.848309] input: PowerA Xbox One wired controller as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input17

[cgutman]

Do you see xpad: loading out-of-tree module taints kernel. in your dmesg?

[kyleabeauchamp]

Nope.

[kyleabeauchamp]

But I do have xpad loaded:

~$ dkms status|grep xpad
xpad, 0.4-powera, 4.4.0-83-generic, x86_64: installed

[kyleabeauchamp]

udevadm info  /dev/input/js0 
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input21/js0
N: input/js0
S: input/by-id/usb-PowerA_Xbox_ONE_liquid_metal_controller_00009EB5014EE6CA-joystick
S: input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-joystick
E: DEVLINKS=/dev/input/by-id/usb-PowerA_Xbox_ONE_liquid_metal_controller_00009EB5014EE6CA-joystick /dev/input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-joystick
E: DEVNAME=/dev/input/js0
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input21/js0
E: ID_BUS=usb
E: ID_FOR_SEAT=input-pci-0000_00_1a_0-usb-0_1_5_1_0
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_MODEL=Xbox_ONE_liquid_metal_controller
E: ID_MODEL_ENC=Xbox\x20ONE\x20liquid\x20metal\x20controller
E: ID_MODEL_ID=543a
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.5:1.0
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_5_1_0
E: ID_REVISION=0101
E: ID_SERIAL=PowerA_Xbox_ONE_liquid_metal_controller_00009EB5014EE6CA
E: ID_SERIAL_SHORT=00009EB5014EE6CA
E: ID_TYPE=generic
E: ID_USB_DRIVER=xpad
E: ID_USB_INTERFACES=:ff47d0:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=PowerA
E: ID_VENDOR_ENC=PowerA
E: ID_VENDOR_ID=24c6
E: MAJOR=13
E: MINOR=0
E: SUBSYSTEM=input
E: TAGS=:uaccess:seat:
E: USEC_INITIALIZED=476604481

[cgutman]

Can you add #define DEBUG_VERBOSE right below the #define DEBUG line in xpad.c and rebuild? It should output some packet dumps in dmesg.

[kyleabeauchamp]

I checked out paroj/master and added DEBUG_VERBOSE, got following:

[  853.590005] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.601961] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.613999] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.625996] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.637996] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.649872] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[  853.650135] usb 1-1.5: USB disconnect, device number 10
[  853.652010] xpad 1-1.5:1.0: xpad_irq_in - urb shutting down with status: -108
[  855.382817] usb 1-1.5: new full-speed USB device number 11 using ehci-pci
[  855.477726] usb 1-1.5: New USB device found, idVendor=24c6, idProduct=543a
[  855.477731] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  855.477734] usb 1-1.5: Product: Xbox ONE liquid metal controller
[  855.477736] usb 1-1.5: Manufacturer: PowerA
[  855.477738] usb 1-1.5: SerialNumber: 00009EB5014EE6CA
[  855.478209] input: PowerA Xbox One wired controller as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input26
[  855.478482] xpad 1-1.5:1.0: xpad_prepare_next_out_packet - found pending output packet 0
[  855.479957] xpad-dbg: 00000000: 80 06 00 00 ba 01 10 00 01 00 00 00 00 00 00 00 00 00 00 00 ba 00 7b 00 16 00 1f 00 20 00 27 00
[  855.479962] xpad-dbg: 00000020: 2d 00 4a 00 00 00 00 00 00 00 00 00 02 01 00 00 00 01 00 01 00 00 06 01 02 03 04 06 07 05 01 04
[  855.480953] xpad 1-1.5:1.0: xpad_prepare_next_out_packet - found pending output packet 0

[kyleabeauchamp]

FWIW, I dug up an old Win7 machine and installed a USB packet sniffer, so I can possibly compare the init packets if that's useful.

[cgutman]

Can you try DEBUG_VERBOSE on my powera_test branch?

Those EPROTO errors look suspect. Can you provide the full log from connection to disconnection?

[kyleabeauchamp]

Your powera_test branch doesn't seem to have any DEBUG_VERBOSE prints, at least by my eye:

https://github.com/cgutman/xpad/blob/powera_test/xpad.c

Seems like paroj/master has the debug prints, but they weren't merged into cgutman/powera_test

[kyleabeauchamp]

On unplug (on master), I see the following:

[ 1525.418326] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.430279] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.442315] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.454278] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.466323] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.478316] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.490277] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.502316] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.514315] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.526314] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.538312] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.550318] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.562315] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.574311] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.586315] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.598314] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.610314] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.622308] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.634314] xpad 1-1.5:1.0: xpad_irq_in - nonzero urb status received: -71
[ 1525.640354] usb 1-1.5: USB disconnect, device number 11
[ 1525.642573] xpad 1-1.5:1.0: xpad_irq_in - urb shutting down with status: -108

[cgutman]

That's quite strange. Does your gamepad have a model number or something? Do you have a link to where you bought it?

I have a PowerA gamepad with the same product ID that works perfectly fine with upstream 4.12 (on which my powera_test branch is based).

[kyleabeauchamp]

According to my order history, it's this one:

https://www.newegg.com/Product/Product.aspx?item=N82E16874822011

Same model number as in picture (zoomed): 1422336-01

[kyleabeauchamp]

FWIW, my packet sniffing experiment has come to a dead end, as I can't find a Win7 driver.