Document HID Controller Interface protocol #23
Comments
|
Alright small update: I managed to identify the code in the steam client that interacts with the Steam Controller. And fortunately, a lot of symbols and assert messages are left over, allowing me to find the official name for more or less every single packet, along with a whole host of packets that seem to be used for other valve hardware - The valve index and steam controller share a lot of code. I'll update the table above with this newfound information as I go. |
|
Hello, I am trying to analyze the protocol of Steam Controller BLE HID, I updated it here, hope it can help you. |
|
Hey @tiehichi thanks for this, it's pretty useful! I've been focusing on this weird proprietary protocol and haven't looked at the actual input reports at all so far :). The HID layer is identical both for BLE, USB and Enhanced ShockBurst (the protocol used to talk to the dongle), so a lot of your findings should apply everywhere. I'll make a PR later today with my latest findings, in a couple of proper markdowns :). I've figured out a couple of interesting things - it seems there's still some hidden features in the Steam Controller firmware that are going to be fun to play around with ^^. |
|
@tiehichi I have previously categorized some of the meaning behind the bytes in valve mode. I think that the second byte is a mode indicator. I haven't dug into what the meaning of the bytes are when the byte is 0x05 but I have the meaning of the bytes when the mode is 0x04. The steam controller seems to have 5 distinct modes; The modes are on the second byte of the packet.
When using more than one mode (aka, buttons and joysticks) these modes are or'ed together. The touch pads modes are on the third byte of the packet. When the touch pads are in use the second byte is set to active and the following mode conditions are set.
Similarly when both pads are in use the bytes are or'ed together for a value of 0x03. Then the inputs always start on the forth byte. When all controls are being touched the controls are on the packet in the order: buttons->triggers->joystick->touchpads. All the input cannot fit on one packet so the right touch pad seems to be left off. When buttons are active they take up 3 bytes of space:
When the trigger is depressed it takes up 2 bytes of space.
When the joystick is active it takes up 4 bytes of space. this can be converted into a short and then divided by 32767 for a float between -1 to +1.
Finally the touch pads can appear in the packet independently. Each touch pad takes up 4 bytes of space and when both are used the bytes the right touch pad uses are shifted so they appear as
|
|
Hey @roblabla , looking forward to your update, these features must be very cool! |
|
Dead? |
This is an issue to gather information about the HID Controller Interface protocol, as described here.
Look at #25 for my current progress.
Old information
The HID Controller Interface is interfaced either via Firmware USB EP3 , Bootloader USB EP1, or via some currently unknown wireless mechanism. It works by transferring buffers of 0x40 bytes. The first byte is a packet id, while the second byte is the length of the additional data. Here is a packetid table containing both bootloader and firmware packets as of 57bf5c10.Host->Controller:
ControllerInfoRequest/ControllerInfoResponse
When sent from Host to Controller, takes no data and asks the controller to send its ControllerInfo.
When sent from Controller to Host: The additional data is an array of HardwareInfo, where HardwareInfo is a structure of one byte (Type) and 4 byte (Data). Here are the different types byte observed:
SetSettings
When sent from Host to Controller: Sets the controller settings. The additional data is an array of ControllerSetting, where ControllerSetting is a structure of one byte (type) and 2 bytes (value). Here are some observed type bytes:
SetDonglePairingMode
Arguments:
The text was updated successfully, but these errors were encountered: