Hey all, my first post to the forum but I've been active in the Discord discussing this stuff with @nefarius , @megadrago88 and @evilC. I decided it's time to put things somewhere a little more organised
The short version:
I'm working on getting XBO Arcade Sticks (E.g. Razer Atrox XBO, etc) working properly on Windows 10 using VigEm. This thread will serve as a development/R&D/discussion log for this project.
The long version:
About 2 weeks ago I picked up a Razer Atrox XBO Arcade Stick. It was on sale and I thought it was the XB360 version. When I got it I discovered that it was, in fact, the XBO version (That's what you get for not reading the product description properly) and the thing with XBO Arcade Sticks on Windows 10 is...well...the don't work...mostly, except when they do....which is only under very specific circumstances.
So first, let's do a bit of a dive into the history of this. If we do a Google search for "Razer Atrox XBO Windows" we get a lot of results:
As you can see, most of them are not positive. The summary of the current situation as it stands is as follows:
- There are two drivers available for use with XBO Arcade Sticks on Windows 10
- The modern driver provided by Microsoft works...but only in applications that use the
Windows.Gaming.Input APIs that are part of UWP / WinRT. In other words, if you want to play only Killer Instinct (Windows Store version) then for you, XBO Arcade Sticks work perfectly. When using this driver, XBO sticks are not exposed as XInput or DInput devices, are not visible to
joy.cpl and can not be used in Steam.
- The beta XBO Controller drivers that were released in 2014. These can be a little tricky to find a working download for but are available. Using this driver your XBO Arcade Stick will be visible in
joy.cpl and is usable in Steam. However, only 6 of the 8 face buttons on the Arcade Stick will be usable. The RT and LT buttons will mysteriously not work...
- On Linux, the
xpad driver implements support for various XBox controllers (original XBox, XB360 and XBO) but it too suffers the 6 button issue
If you like watching videos, here is one I put together on YouTube which walks through the issue:
For further details, I'd recommend reading the following links:
The quest begins...
So, after digging up all this information my first impulse was to simply return the device and instead purchase one that was XB360 compatible as those all work fine on Windows. However, I was somewhat curious and so I began doing a little bit of digging.
First, I installed a piece of software called Device Monitoring Studio. DMS, much like Wireshark + USBPcap, is able to inspect the traffic sent and received by USB devices. Using DMS I hooked into my Atrox and took a look at what happened when I pressed the various buttons (including the ones that didn't work). Sure enough, the controller sent signals as it should. For all the buttons. And it did so even though DMS is not a UWP / WinRT application. My interest was piqued. Clearly the issue was not the device or its communications with Windows. The problem of the stick not being exposed as an XInput device could be due to a bug in the generic MS driver for XBO peripherals on Windows, or maybe just an oversight. Who knows, maybe even intentional, who's to say. However, it was still really strange the using the old drivers or on Linux that only 6 of the 8 face buttons worked. What could be going on there?
After looking at the data harvested by DMS though, I was pretty sure there must be some way to work around this. It wasn't as if the data sent by the controller was especially complex. This lead to search for virtual controller tools and in turn led me to VigEm. I joined the Discord and began to make inquiries.
@evilC suggested I take a look at the
Windows.Gaming.Input APIs and with some help with @Sylveon I was able to quickly throw together a modified version of the VDX sample application that was able to interact with the Atrox using the
Windows.Gaming.Input.ArcadeStick API. It worked quite nicely, except for one problem. The
Windows.Gaming.Input family of APIs have a rather specific limitation which is that they only work when the application using them is running in the foreground. This the plan of a modified version that would use
Windows.Gaming.Input to feed input to a VigEm controller was sadly doomed to fail.
Back to the drawing board...
Windows.Gaming.Input route wasn't going to work and stepped back and started looking at other options. @megadrago88 suggested investigate interacting with the device via HID. Initially this looked promising but after obtaining the HID descriptor it seems like that avenue is also a dead-end as the device is vendor specific and has no HID descriptor.
Meanwhile, I had been collecting more USB packet data using DMS and also reading the source for the
xpad driver and the documentation it referenced with regards to the XBO controller data structures:
Comparing these, I noticed something:
- According to the XBO protocol docks, an XBO controller sends 18 bytes of data for a button data message
- DMS recorded information from my Atrox reflected a 30 byte message
- According to the XBO protocol docks, bytes 7 through 10 are used to send through the LT and RT
- However, with the DMS recorded information from my Atrox, these bytes were unused
- Furthermore, and even more interesting, the 23rd byte in each button press packet contain data that mapped through to the buttons pressed, including the LT and RT
Based on this my hypothesis is as follows:
- XBO Arcade Sticks do actually behave differently from standard XBO controllers
- One key difference is the location of the data they send for the LT and RT presses
- As a result, the
xpad driver does not handle the LT and RT presses because it looks for them in the wrong location in the data
- I suspect the reason the beta XBO drivers for Windows work in the same way is that they too treat the device as a standard XBO controller and thus look for LT/RT presses at the wrong location
The road forward...
Now that my preliminary investigations are done I am planning the following dependent tasks:
- Test my hypothesis about the arcade stick data by modifying and testing
- Ask users from https://www.reddit.com/r/Fighters to participate in some data collection using DMS to confirm/deny whether other XBO Arcade Sticks send data similar or identical to that of the Atrox
- If the
xpad test is success, I will use ZaDig in conjunction with a VigEm client application in order to expose the Atrox (or maybe even ALL XBO Arcade Sticks) via VigEm as a XB360 controller with all its buttons working as they should
And that's the long story. I'll update this thread with new details as I go.