XBO Arcade Sticks, VigEm and a whole ton of "fun"...

Another quick status update for today:

Tried fiddling with xpad a little further, no luck, back to WinUSB I guess.

Now...WinUSB is proving to be much more successful! I tweaked the example WinUSB application a little more today and achieved two useful things:

• Successfully queried the device for end-points and was relieved to discover that the two end-points I collected in my USB packet sniffing with DMS were the exact same and only end-points reported by the device. Nothing hiding it seems
• Was able to successfully send the Controller Init/Keepalive packet. This is a small 5-byte packet. Interestingly, according to the xpad source these 5 bytes should be 0x05 0x20 0x00 0x01 0x00 but based on the packet sniffing for the Atrox what I should be sending is 0x05 0x20 0x08 0x01 0x05. Maybe another difference between the Atrox (and maybe all XBO arcade sticks?) and normal XBO controllers? Time will tell...anyways, I was able to send the latter packet version to the device and keep it alive and connected for a minute (at which point the for-execute-sleep loop in my code ended) which is great!

Overall, I'm really pleased with the quick progress I've made with WinUSB. Many thanks to @nefarius for suggesting the ZaDig + WinUSB route, it's proving very fruitful!

Didn't achieve too much tonight, did some investigating around the speed of the Atrox. It seems it's a full-speed device with a polling interval of 4ms for each of the end-points.

In theory this means requests to either end-point are guaranteed to complete in 4ms or less, according to USB spec anyway.

Interesting...I think

Some testing tonight that produced good results.

The main thing I tested tonight was actually receiving button input. This went quite well. I was able to receive button press data and additionally confirmed once again the 23rd packet being used to send the LT and RT buttons. There were one or two interesting things noticed during the input test:

• After sending the init packet the very next step should be to make a read request against the input end-point. Failure to do so will result in the Atrox disconnecting unless a steady stream of init packets are sent.
• After sending the init packet and requesting button press data an immediate response seems to be returned of the 30 byte packet type. Since this happened pretty much the second I ran the test program and had no buttons held this packet obviously indicate no buttons pressed
• The next packet sent by the device is a bit odd, sitting at only 2 bytes long, with byte 1 being 0x01 and byte 2 being 0x0. This is not mentioned in any of the documentation on XBO controllers and I didn't observe a packet of this length when capturing previously using the normal drivers.
• The next two packets were another 30 byte and 2 byte packet, then I received an 8 byte packet which is most likely the heartbeat packet I recorded previously (although I should confirm this)
• It's possible then that this models the initial handshake of the device. In other words: Send init packet, then read data and wait for 30 byte packet, 2 byte packet, 30 byte packet and then another 2 byte packet. I should probably do some more testing, maybe with a button held down before starting the test application. I could well be making an assumption here
• Once the handshake (if that is what it is) has been performed the device will stay connected and send heartbeat packets pretty regularly if not input is submitted.

I think after doing a little more investigation around the 2 byte packets I should be able to start integrating with some code that actually forwards the data on to a VigEm controller

Rather slow week on my end. Been super busy with work and also trying hard to get over a nasty cold that has the whole family feeling low.

Still, some progress achieved. Rather than forging ahead with the VigEm integration I decided to clean up the WinUSB sample application and turn it into a more general-purpose application than can be used to play with the Atrox.

Good thing I decided to do so, since it helped me figure out a few issues that would probably get in the way later when I start integrating with VigEm. Once the application is working fully I'll post a link to the GitHub repo and release binaries, etc then move on to phase two, integrating with VigEm.

Tada!

Test application done!

https://github.com/OOPMan/RazorAtroxWinUSBTest

Next step, integrating with VigEm

Quick second update for the day. I've spun of a new project that will provide the first, simple integration between the Razer Atrox, WinUSB and VigEm.

The application will be quite basic (I.e. Another terminal application using pdcurses) with the aim being to achieve a stable, performant integration between the components mentioned in order to allow for testing with actual games and other applications to be pursued.

Assuming this project goes well I can then look at a more user-friendly implementation

Quick update. Nothing of value was done this week, I was out of action with the flu.

Going to try and make a proper start on the next phase of this project this weekend and hopefully achieve something of value by the end of next week.

Some most excellent news. The phase two application that pipes input received from the Razer Atrox via WinUSB through to a Virtual XB360 Controller provided by VigEm is complete to the point that I was able to fire it up, start Mortal Kombat 11 and play around in the Practise mode.

The test was a resounding success, all buttons worked perfectly (including menu, view and guide) and there was no noticeable input lag as far as my casual eyes and fingers could tell.

At some point I want to write a basic application that will register the exact time (down to as small a unit as possible) that an input even from the virtual controller is received which can paired with similar functionality in the feeder application to collect a good amount of data on the extent to which there is input lag. For now, though, initial signs are good.

I'm going to test the feeder a little more this week and put together a YouTube video demoing it in action as well. Assuming all goes well I will then begin looking for testers along with folks to supply USB packet data from additional devices.

I'll also need to think about next steps with regards to the application. It would be useful, in the long run, to support multiple controllers (this is apparently possible with WinUSB...apparently) and maybe also a GUI and possibly even some install tools to get users up and running nice and quickly.

For now though....time to test

Forgot to mention it here, but I posted the first test version to /r/fighters: https://www.reddit.com/r/Fighters/comments/bjmca9/attention_razer_atrox_xbo_owners_other_xbo_arcade/

Movement on it has been slow though. Maybe everyone trying to use an Atrox XBO on PC already got tired of fiddling and sold theirs

Well, anyway, I need to start thinking about doing a more user-friendly version with some kind of GUI. Maybe something that can auto-install the WinUSB driver and so forth.

Finally saw some activity on the Reddit topic. It seems like there were some issues with the WinUSB drive bundle I built so I had to put together a ZaDig guide. I've also updated the README file for the project on GitHub

Well, anyway, there is now one other confirmed user of the tool and he/she seems to be very happy to have full use of their Razer Atrox XBO

I've been spurred on to put together a roadmap for the tool:

• Improved GUI (Text-mode first, later a proper Win32 GUI)
• Advanced Input rebinding and presets system
• Input modifier system to allow a button on the controller to be used to trigger alternate input mode. Similar to the Shift key on a keyboard
• Support up to 8 controllers
• Integrate libwdi to integrate WinUSB driver generation and installation into the application
• Support other XBO Arcade Stick controllers that do not work correctly on Windows