Controller model 1537 compatibility about xow

[denharad]

I have a bulky adapter, model 1713
Worked fine for a quick arcade game I fired up. Seemed to get some random vibration sent through during game launch but that may have been the game. Pretty sure the controller & adapter were already paired as it picked the controller up immediately when powered & noted it when I turned it back off. Let me know if there is a good way to test all the functionality of the controller, and/or you need packet capture.

2019-12-22 13:15:17 INFO - xow v0.2-2-g297efa4 ©Severin v. W.
2019-12-22 13:15:17 INFO - Dongle plugged in
2019-12-22 13:15:17 INFO - Chip address: 62:45:b4:ec:b7:90
2019-12-22 13:15:17 INFO - Dongle initialized
2019-12-22 13:15:45 INFO - Controller '1' connected
2019-12-22 13:25:31 INFO - Controller '1' disconnected

[TheVetter]

I also just tested my controller on arch linux I was able to play borderlands 2 just fine for the 30 minutes I played.
Controller model 1697.

This is such a great project would love to help

[Dragon20C]

Hello! (I'm from the reddit post)
At the moment I'm not at the computer today but I did some trys last night and on arch Linux looks like my dongle was detected but produced no results, like it didn't connect to controller or produce led sign saying its trying to connect, now something I know for sure is, my dongle isn't the original so we might be also dealing with clones! I'll do more testing when I can!

[medusalix]

@TheVetter Good to know 👍. I changed the model 1697's status to working in the README.

@Der-Eddy So your old dongle worked correctly with this driver? That's interesting because we had an issue with the macOS version of this driver where the old dongle didn't work, so I assumed it wouldn't work on Linux either.

@dragon212c What model of the controller are you using?

[Dragon20C]

@medusalix I think I have the xbox one original controller the bone stock one! (1697)
I should have some free time tomorrow and I will see what I can do!

Edit 1: Unplugging the dongle in and out from the konsole tells me it is detecting that a dongle exists BUT I cant seem to get it into sync mode to connect the controller!

Edit 2: I also seem to have a different chip address compared to @denharad my is Chip address: 62:45:b4:e7:a4:ef im not sure if they are support to be different or not.

[offalynne]

1697 and 1708 paired and working correctly with bulky dongle

[Der-Eddy]

@medusalix jop Bulky adapter model 1713 working under Linux with Xbox Gamepad 1708
I even updated my Gamepad firmware today to version 4.8.1923.0 on Windows and it still works, if thats matters at all anyway
though I get the same bug as in #3 using the latest commit 297efa4 in Proton/Wine games, native games works completely fine

[medusalix]

Thanks for all of your feedback, I've update the README accordingly. It looks like the model 1537 is currently broken (with the old dongle). I'd suspect this is related to the controller and not the dongle (additional confirmation would be great).

[Dragon20C]

@medusalix I cant seem to get the dongle to go into sync mode so I cant test if the controller is the issue or not, cant really confirm.

[medusalix]

I also seem to have a different chip address.

Yes, every dongle and controller has an unique MAC address.

I cant seem to get the dongle to go into sync mode so I cant test if the controller is the issue or not, cant really confirm.

Yeah, we'd need someone with the newer dongle and controller model 1537 to test it.

@dragon212c Please do one packet capture on Windows (where it works) and another one with xow on Linux.

[madjam002]

I'm currently testing the latest commit (5c7ead6) with the old bulky USB stick and 2x 1708 controllers, 1x 1697 controller and 1x 1537 controller all connected at once.

The 1697 and 1537 controller were difficult to pair, I had to pair them on Windows and then switch to Linux, this might be unrelated to this project as even on Windows it took a few attempts to pair. Once paired they worked for a few minutes on Linux but they both had issues where they would disconnect, the white light would start flashing, and would reconnect a few seconds later. This is what I see in the logs:

Jan 01 19:23:24 media xow[755]: 2020-01-01 19:23:24 INFO  - Controller '3' connected
Jan 01 19:29:01 media xow[755]: 2020-01-01 19:29:01 INFO  - Controller '3' connected
Jan 01 19:29:07 media xow[755]: 2020-01-01 19:29:07 INFO  - Controller '3' connected
Jan 01 19:33:37 media xow[755]: 2020-01-01 19:33:37 INFO  - Controller '4' connected
Jan 01 19:34:10 media xow[755]: 2020-01-01 19:34:10 INFO  - Controller '4' connected
Jan 01 19:41:18 media xow[755]: 2020-01-01 19:41:18 INFO  - Controller '4' connected

When this disconnect happens, the controller doesn't log a disconnected event, just a connected event. Looking inside /dev/input as well, I see that when they disconnect they show up as a new jsX device, leaving old orphaned devices which no longer respond to any input (e.g I have a js1 device, but when the controller disconnects and reconnects, it connects as js2, leaving js1 present but it will not show any interactions using jstest for example)

The two 1708 controllers were more reliable, they both paired quickly on Linux. One of them worked for the entire duration of my session (around 30 mins), but one of them stopped responding to any input after about 20 minutes. Unlike the older controllers I mentioned above, this controller didn't disconnect (the white light on the controller stayed solid), it didn't reconnect, and just permanently stopped responding to input. The only way to get it to work was to power off the controller and turn it on again. It then connected as Controller 2 again but under a new js device.

If there is anything I can do to help debug these issues further let me know! Thanks so much for this project

[medusalix]

The 1697 and 1537 controller were difficult to pair [...]
[...] they both had issues where they would disconnect

Please do a packet capture (like I described in my previous comment).

When this disconnect happens, the controller doesn't log a disconnected event, just a connected event.

Yes, that also happens when they go out of range. When you build xow with BUILD=DEBUG you should see reconnect events in your console. The old js devices should however disappear (they are closed in the destructor). I tested it on my system and it worked correctly (when it reconnected, js2 disappeared and js3 got opened). Maybe jstest prevents the files from being deleted.

[...] and just permanently stopped responding to input

Would be really helpful to packet-capture this as well.

Thanks for taking your time to debug these issues.

[ZVNexus]

Heyo, I own 1537 and my dongle is 7632. I wasn't really sure how to grab a packet capture, but everytime the service failed this popped up in Wireshark, so thought it might what you're looking for.
1537-7632.zip

@medusalix

[medusalix]

@ZVNexus Your capture is unfortunately not related to the dongle's operation. I ordered an old 1537 controller today, so I'll have the right hardware to debug this issue soon.

EDIT: The only problem remaining seems to be that the pairing doesn't work. Once you've got the controller connected it works just fine. I still haven't figured out why it doesn't pair though...

[medusalix]

I've made some changes to the pairing logic in 3cbc665, which allows 1537 controllers to pair with the dongle. The pairing process is very unreliable right now. I'm pretty sure I've identified the issue, but I don't know how to fix it:

These are captures of the wireless traffic during the pairing process between the dongle and the controller (left side is Microsoft's original driver). The marked packets are the pairing request (sent by the controller) and the dongle's pairing response. The issue I've ran into is that the pairing response sent by xow is apparently not received by the controller (no acknowledgement). The dongle tries to retransmit the packet three times before finally giving up. I'm honestly at my wit's end right now, so unless some technical person intervenes I guess we'll have to put this issue on hold.

[medusalix]

So apparently one of the recent commits (76fac9f) that fixed the occasional disconnects also resolved the prevalent pairing problems with the 1537 controllers. The only issue that remains is the double-association the controller performs right after the pairing (which doesn't impact the usability in any way):

@Der-Eddy @offalynne I'm not sure whether you guys actually own a 1537 controller, but if you do, I'd appreciate if you could confirm my findings.

[offalynne]

i do not, sorry

[medusalix]

Double-association has been fixed in commit a6bbfe4 (see screenshot). Pairing 1537 controllers is now working.