-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New command #5
Comments
After more poking around the command format is actually found to be at least this 0a 20 <- led command fuzzing of random values accidentally activated several flash patterns too so there is more to be found |
This is as far as I am going to go, this is how I am using it 0a 20 <- led command
|
Nice job figuring all that out! It's always nice to see people doing something similar I did. If you create a pull request with that information I'll happily merge it. How did you find out what messages the Xinput driver is sending to the controller? I think some kind of USB sniffer might be able to record those messages, but are there also some software only ways of getting that information? |
In order to create a pull request I have to fist check out this github to my own account or something right? Im pretty new to this github thing I have been using both wireshark+usbpcap and "microsoft message analyzer". Each has pros and cons. I prefer wireshark's interface but MMA provides about 10 times more information. This is all under windows of course. I think wireshark natively supports usb capture under linux. Also after watching the packets for a while, I would suggest (but im not positive) that the 01 message is either a command, or an ACK/response, or both. The 4th byte is total packet length (as it is for all packets) and the 6th byte is always the first byte of a nearby packet. For example
will always be near a packet that starts with
where 06 is the command byte. Im not positive what 06 is. There is a long stream (maybe 30?) of 06 commands (of 64 bytes each) during handshaking that might be memory reads or something (there seems to be a small amount of text in one ). The only thing that leaves during init is the 0a command. This command is not replied to and I focused on that. |
Thanks for the reply, it's nice to know what tools can be used if I decide to continue reverse-engineering the protocol. I want to test out how those tools work, but don't have the time to do it now. The Pull Request process goes like this:
Just ask if anything is unclear. Also don't worry too much about even if you are not sure about some packets. Your guess is as good as anyones and we can always improve the information later on. |
I wanted to try to control the LED on the xbox controller so I did a little poking around...
The Window Xinput driver sends this command, which makes the LED a little dimmer than the maximum:
0a 20 04 03 00 01 14
Im sure its doing more than just the LED, but anyways I got what I wanted in 4 tries.
0a 20 04 00 00 01 14 - led appears to be max brighness
0a 20 04 02 00 01 14 - a little dimmer, possibly the same as 03, or maybe a little different
0a 20 04 01 00 01 14 - led off
this is on an older controller with no headphone jack.
PID: 2d1h
VID: 45eh
Address (#1) assigned.
Manufacturer : Microsoft
Product : Controller
Serial Number : 7EED8E29D8E9
The text was updated successfully, but these errors were encountered: