HID/HCI Debugging + Button Press #293
Replies: 3 comments
-
|
In case anyone else needs it as it's poorly documented you can use Windbg for debugging. Having gone this route, I would say that the usbpcap option is likely better for most people, however a useful option none the less. Once windows debugging tools are installed: Enable Kernel Debug: From CMD (administrator) Attach to Kernel in windbg Load HID dll Reload with Check HID Tree Check Pre Parsed Data (look for hidppd) - These are the advertised details, Report ID, usage, Ranges, |
Beta Was this translation helpful? Give feedback.
-
|
For the axes the norm for gamepad is for the field to be an unsigned absolute value. For a 16 bit field the neutral value will be 0x8000 for example. For 32 bit 0x80000000. ESP32-BLE-Gamepad is not a good example of what a typical gamepad from the industry does. BlueRetro handling of generic device is far from perfect but I really don't have time to make it better. So your best bet is to make your controller behave just like an Xbox X|S controller by using it's descriptor and making the report match that descriptor. Here special build of BlueRetro which dump the packet on serial: Setup your serial port as described here: "Implicit CR in every LF" setting is important. Save the log in a txt file and import in Wireshark as described here: At the "HCI trace in your own code" section, one addition to make is to add in timestamp format field: %S. (notice the dot after S) |
Beta Was this translation helpful? Give feedback.
-
|
I was able to run a brief test and confirmed the issue is isolated to the negative value. In this case simply setting advertised range from 0-32K (removing all negatives) resolved the issue. This appears to be more an issue on BlueRetro side correctly understanding advertised ranges with negative values however I understand the potential wide impact to the codebase modifying to address this issue. Either way issue is addressed, thank you! |
Beta Was this translation helpful? Give feedback.
-
Looking for some assistance in how to debug HID/HCI transactions post initial controller negotiation. I was able to enable HID debugging in the windows kernel and capture details as well as leverage Ubertooth to grab over the air packets. While this helps identify advertised details, it doesn't provide much in the way of useful details on button press debugging.
For context, I am currently attempting to debug some issues with erroneous input on a joystick (Saturn ALT mode). I am particularly perplexed as on windows and Linux I see negotiation complete and all buttons work as expected. Blueretro immediately connects however specifically stick input consistently toggles even when specifically ensuring return to 0 is received.
I am using the https://github.com/lemmingDev/ESP32-BLE-Gamepad/ library. Descriptors leveraged area defined in this file (seem similar to common joypad minus ranges): https://github.com/lemmingDev/ESP32-BLE-Gamepad/blob/master/BleGamepad.cpp
One specific thing I have noted (and may be unrelated) is that it appears BlueRetro may not like NEGATIVE values. The library defines -32K to +32K as a range (0 center). Positive stick values seem to work for the most part however negatives do not. Triggers for example in my code are sending 0-+32K and work correctly, however stick details using the full 64K range do not. This may explain the behavior as if negative values are losing "negative" in the translation effectively either direction on the stick would return a positive value - RIGHT for example vs Left.
I have also looked through documentation here and appears to demonstrate the same issue - capturing advertised features but not active input changes: https://hackaday.io/project/170365-blueretro/log/178249-learning-bluetooth-classic-bredr-with-hci-traces
Beta Was this translation helpful? Give feedback.
All reactions