|
|
Here’s what I’ve figured out so far: If you’re buying a wireless gaming receiver or wireless controller, or any other Amazon item, please consider using my affiliate link: You can also just donate to me if you find this info helpful and want to thank me, see the OSX driver page for more details :)
USB Info
Vendor: 0x045e (Microsoft)
Product: 0x0719
Version: 0x0200
Class 255, subclass 255, protocol 255
Interface 0: class 255, subclass 93, protocol 129
2 interrupt endpoints: in, out
Interface 1: class 255, subclass 93, protocol 130
2 interrupt endpoints: in, out
Interface 2: class 255, subclass 93, protocol 129
2 interrupt endpoints: in, out
Interface 3: class 255, subclass 93, protocol 130
2 interrupt endpoints: in, out
Interface 4: class 255, subclass 93, protocol 129
2 interrupt endpoints: in, out
Interface 5: class 255, subclass 93, protocol 130
2 interrupt endpoints: in, out
Interface 6: class 255, subclass 93, protocol 129
2 interrupt endpoints: in, out
Interface 7: class 255, subclass 93, protocol 130
2 interrupt endpoints: in, out
From this, I suspected that the wireless protocol was handled entirely within the dongle. On the plus side, this meant it’d be fairly easy to write a driver - on the downside, only 4 possible controllers could be used at once. Still, that’s Microsoft’s decision, and so nothing for us to worry about (and you could always use two dongles on one machine). Basically, the same two interfaces are repeated four times - one for each of the four potentially connected controllers. I have not yet deduced what the second interface of each is for, but I assume audio, or serial communications (or both). The first interface allows you to interact with the controller, detecting whether it’s connecting or disconnecting, getting reports and setting the LEDs and rumble.
Reports from the device
A number of different length reports will arrive from the dongle on the interface. I believe that byte 1 indicates the meaning in most cases.
Got 2 bytes: 0880
Got 29 bytes: 000F00F0F0CCFD0CD17048B0F100000513E7201D300340015001FFFFFF
Got 29 bytes: 00000013A2000000000000000000000000000000000000000000000000
Device connection
Got 2 bytes: 0880
Got 2 bytes: 0800
These messages are sent when a controller attaches or detaches from the receiver. An attachment could be the controller being switched on, or it being paired with the receiver. Detached generally means the batteries being pulled out. I’ve only seen the two results, byte 0 is always 0x08 and byte 1 is 0x80 when a device appears, and 0x00 when a device disappears.
Initial info
Got 29 bytes: 000F00F0F0CCFD0CD17048B0F100000513E7201D300340015001FFFFFF
This message seems to be sent when a device is first connected - most of the values stay the same for any given device, the only ones that seem to differ between same model controllers are the 4 bytes beginning at 0x0A, which I assume to be a serial number. Other flags I assume to represent device type, although I’ve not got any non-controller devices (e.g. steering wheel or headset) to identify these fields with. Finally, some of the values I believe to be the initial states of various readouts, such as battery level. I believe the code 0x13 represents battery status, and it’s position and value in the array are 0x10 and 0x11.
Info update
Got 29 bytes: 00000013A2000000000000000000000000000000000000000000000000
Got 29 bytes: 0000004001000000000000000000000000000000000000000000000000
Got 29 bytes: 0000000005000000000000000000000000000000000000000000000000
Got 29 bytes: 000000F000000000000000000000000000000000000000000000000000
These codes are occasionally sent by the device, and I believe they update parameters such as battery level as time goes on.
Suspected code meanings
| Value |
Meaning |
0x13 |
Battery charge level |
0xF0 |
Device low power mode (HID updates will stop until controller inputs change) |
HID Report
Got 29 bytes: 000100F0001300000000D403B60651FCFE030000000000000000000000
This message occurs when a value changes on the controller, such as the user moving a joystick or pressing a button. The updates will temporarily stop when the user stops, which also results in a notification as mentioned in the above section. The same flag from the above section, 0xF0, is also present here. To handle this data, simply take the buffer from byte 0x04 - from here it is in the same format as the wired controller reports, although the data is a slightly different length (byte 0x05 or byte 0x01 once the leading bytes are stripped).
Unknown reports
Got 29 bytes: 00F8010000000000000000000000000000000000000000000000000000
Got 29 bytes: 00F8020000000000000000000000000000000000000000000000000000
I currently have no idea at all what these represent, along with the other "value" updates from the Info Update section.
Reports to the device
As with the wired controller, it is possible to control the rumble motors and LEDs.
Setting the LEDs
00 00 08 vv 00 00 00 00 00 00 00 00
This report will set the LEDs. The new LED mode is defined by vv - this is basically the same value as you would pass to the wired controller, but with 0x40 added.
Setting the rumble motors
00 01 0f c0 00 bb ll 00 00 00 00 00
This report will set the rumble motors - bb is the value for the large motor, ll is the value for the small.
Other functionality
I have not yet figured out how to power down the controller, or how to read/write the audio port. Additionally once the new keyboard is released, it will be necessary to support the serial port to get that to work, with both the wired and wireless receivers.
|
