In the previous post an introduction to USB protocol was presented.
Given what was learnt in that post, the next step for the Remote Xbox Project is to both figure out how to extract data from the wireless Xbox controller and make sense of it.
The first step in this process is to identify the different Interfaces and Endpoints within the device.
To do this the I used lsusb from usbutils on my raspberry pi obtained using
$ sudo apt-get install usbutils.
After connecting the controller, I then used the command
$ lsusb, which returned the list of USB devices currently connected to my raspberry pi and looked like this:
As you can see, the Xbox controller is Device number 5 and has a Vendor id of 045e and a Product id of 028e in hex. We can now use lsusb to inspect it in more detail using the command
$ lsusb -d 045e:028e -v
, where
-d
shows only the device of the specified vendor and product id and
-v
provides more detail.
As you can see from the results above the controller has one Configuration with four Interfaces and no Alternate Settings to worry about.
Interface 0 has two Endpoints, one IN and one OUT; Interface 1 has four Endpoints, two IN and two OUT; Interface 2 has one Endpoint, an IN; and Interface 3 has no Endpoints.
Also of interest is the fact that all the Endpoints are of the interrupt transfer type.
Now that we’ve established the details of the different Interfaces and Endpoints, and most importantly their addresses, we need to figure out what processes they correspond to and where to extract the controller inputs from.
Fortunately, this has already been done within Tattiebogle’s post on wired controller information.
He found that Interface 0 corresponds to the data from the controller, including the status of components such as the rumble motors, the LED ring and whether the headset is present, as well as the controls status.
He also speculates that Interface 1 is for the audio data for the mic and speaker in the headset and Interface 3 is a security measure used by Microsoft to check that the controller is licensed.
This latter point makes sense due to the lack of Endpoint associated with Interface 3 and the presence of what appears to be a proprietary chip on the controller circuit board.
This also has implications for item three on the checklist, replicating the inputs on the server side as outputs to the 360 console, and as such will be discussed in more detail in a later post.
No speculation is offered for the role of Interface 2.
As it possesses only a solitary IN Endpoint, I reckon it could be for the chatpad accessory.
This is something I’ll be investigating further, once I acquire a chatpad, along with extracting data from the Endpoints in the next post.