xpad
xpad copied to clipboard
paroj
One S and elite series 2 not connecting over usb
I am struggling to get either of my new xbox one S pad Or elite series 2 pads to connect to my linux vm. My vm is running an rhel 7.3 variant and my host is rhel 6.9.
Looking through wireshark usb captures i am seeing the irq out messages get stuck.
I see the 2015 firmware message send and the irq status response come back. Then the new s pad message sends but no response message comes back to the completion callback. After this the irq in messages stop. And the driver seems to go idle. Pressing the mode button just results in a flashing button, no new messages appear.
What else should I try to troubleshoot this?
A little more info... I attached a usb sniffer and found that the second init packet 05 20 01 0F 06 is forever nak[ing] from the device
What firmware version is your controller on? and is this the Xbox One S or the Elite Series 2?
The xbox one S is running 3.1.1221.0 Ill have to check the elite series 2 version tomorrow. Both controllers exhibit the same behavior.
I can confirm the new version 4.8.1923.0 has the same issue. I did an update on the series 2 as well and it still acts the same. Interestingly the series 1 works fine... The only thing I can think that could be happening is qemu-kvm is configuring the usb passthrough and botching the device init such that both the host and the guest are requesting device enumeration but the sniffer doesn't show the messages racing eachother.
If i stop the close function from killing the irq in urb i get the 500ms 0x02 0x20 messages continually. Any chance this message cryptically details my error? Haha...
That is very odd. The 05 20 01 0F 06 packet is new with 77dd82a490689353731435ecbf239ddb4df4cc14 but I personally tested that patch with my 2 Xbox One S controllers, one on 3.1.1221.0 and one on 4.8.1923.0. I tested it again today to make sure I didn't screw something up, and it definitely works for me.
Can you remove the VM from the equation and just use xpad on the host?
Hmm, I'm very sorry, I thought I'd mentioned that it works on a bare metal machine. Ive been Playing with rhel7 on rhel7 and found that the message sequences captured by the sniffer look very similar but if I send 0 into the authorized control in /sys/bus/usb/devices/
Ah ok. Does it help if you revert https://github.com/paroj/xpad/commit/77dd82a490689353731435ecbf239ddb4df4cc14 ?
Nope, not even the windows vm seems to knock it into submission. Maybe the hardware locked?
I got some powerA xbox one controllers and they worked... something about these new Microsoft controllers must not like the double enumeration that's happening.
Sorry to keep spamming. I think I finally found the culprit although I am unable yo prove it. I noticed that the get device descriptor setup message is not getting sent before the set address message. Ive been trying to trace this through qemu and into the host devio but had to leave early today... Do you know of any simple way i can bypass this? Making the call through the driver or detecting that the device is in a bad state?
Still trying to trace this down. I finally was able to force the new controllers to work by removing the call to usb_reset_configuration in the host kernel. Whats happing is... The guest is completing the device enumeration and the last message in that process is a set configuration packet which bounces down into qemu-kvm which intern makes an ioctl call. The ioctl for USBDEVFS_SETCONFIGURATION inevitably calls usb_reset_configuration in drivers/usb/core/message.c.
I know this isn't the xpad drivers shortcomings but if anyone has any thoughts as to what is happening I'm all ears.
