WIP: Windows report descriptor reconstructor unit test #343
No reviewers
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi!343
Loading…
Reference in a new issue
No description provided.
Delete branch "windows_report_descriptor_reconstructor_unit_test"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR is based on #306 and implements a unit test, which allows to test the report descriptor reconstructor offline, whithout access to HID devices. It runs on GitHub build actions.
To allow this, I stored the preparsed data of the HID devices in text files. The test reads this data and executes the reconstructor code and compares the output with a reference file.
For each HID device, the unit test contains 3 files:
*.pp_data -> Text file with the Preparsed Data
_expected.rpt_desc -> The expected output of the reconstructor
_real.rpt_desc -> The real report descriptor of the device
My first and general comment: lets have all (unit-)testing related infrastructure under
HIDAPI_WITH_TESTSCMake optionI'll check everything else a bit more close later
@ -0,0 +1,459 @@#include "../hid.c"@ -0,0 +1,459 @@#include "../hid.c"Done
For now this unit test is to ensure, that I don't break anything, when I start cleaning up the code in #306.
I lost the overview over all the test results in the comments of these PRs. Now I just need to add a new HID device once, and get the result immediately with each build.
@mcuee I created a small helper program in https://github.com/JoergAtGithub/hidapi/tree/windows_preparsed_data_dump (Build it and you get pp_data_dump.exe) which dumps the preparsed data for each HID device into a text file. Could you do this for your test devices and provide me the files.
That's awsome, thanks.
Great. I will carry out the tests over the weekend.
First thing: Windows solution files have not been updated in hid\Windows directory.
Cmake build is okay.
Zip of the dump data
dump_windows10_dell_laptop.zip
.
@mcuee I added tests for your devices, where I could find the real report descriptor in the comments from #262/#306. Without the real report descriptor, I can't check the correctness of the generated data.
Could you please provide the real report descriptors also for:
Unfortunately I do not know how to get the real report descriptor of the following built-in HID devices.
As for the Plantronics Blackwire 3220 Series 047f c056, I think I have posted it before, I get it from macOS USB Prober application. Let me check where I posted it.
Edit to add: sorry the following is for 047f:c025. I will get 047f:c056 later.
https://github.com/libusb/hidapi/pull/306#issuecomment-883033225
macOS USB Prober output for the Plantronics C320-M USB Headset (Blackwire 3220 Series USB Headset). This is a pretty complicated device.
click to expand
@JoergAtGithub
Here is the output from macOS USB Prober about 0x047F/0xC056 Plantronics headset.
hut1_12v1_apendixB_delimiter_example.txt
@mcuee: I attached a file hut1_12v1_apendixB_delimiter_example.txt , where I typed manually the report descriptor for the the Delimiter Example from the USB HID Usage table specification 12v2.
The delimiter feature, where a device (or control) can have multiple alternative usage pages/usages is not used in any of the real example devices. And the official example covers several edge cases.
Could you try to program this report descriptor to your Microchip PICkit device, and than read the Report Descriptor using MacOS and pp_data_dump.exe on Windows?
This may take some time. I have not really touched the PIC FW development for a long time.
But let me try during the holiday period. I have long holiday in December and I can not go anywhere anyway.
If you can do this, it would really help. Because this functionality is quite complex, and I've no data to test the code.
Do you see a chance to program the hand coded ReportDescriptor from https://github.com/libusb/hidapi/files/7528936/hut1_12v1_apendixB_delimiter_example.txt ? This would cover the last untested feature of the report descriptor syntax.
If it helps, I can create physical devices that return arbitrary HID Report Descriptors and test what Windows hidapi is returning.
I've been making a small collection of descriptors useful to me in
descriptors.hof thistest_hardwaresketch that runs on any MCU supported by TInyUSB: https://github.com/todbot/hidapitester/tree/master/test_hardware/hidtest_tinyusb@todbot : That would be great!
What I need, to complete the coverage of the test case, is the report descriptor from https://github.com/libusb/hidapi/files/7528936/hut1_12v1_apendixB_delimiter_example.txt
This is the hand encoded descriptor of the "Delimiter Example" from the "USB HID Usage table specification 12v2".
You need to connect the device to a Windows PC and execute
pp_data_dump.exewhich dumps the preparsed data into a text file.pp_data_dump.exeis a quick and dirty helper program, which I created in https://github.com/JoergAtGithub/hidapi/tree/windows_preparsed_data_dumpJust build it like hidapi. It's similar to the hidapi example program.
If you want to try the report descriptor reconstructor itself, execute the 'hidtest.exe' example program from https://github.com/libusb/hidapi/pull/306
I'm actively reworking this one (test infrastructure and implementation).
Expect this one to be completely updated (in a separate branch) in a few days.
@todbot Are you still intend to program the Report Descriptor with the missing test case to your TinyUSB device? It would be of great help!
All of these changes are now in https://github.com/libusb/hidapi/tree/get-descriptor .
I still have too many questions to the implementation, and I intend to refer to those before making a PR to master.
One of the items to work on - include pp_data_dump so the dumper is a part of this repo too.
In any case, at least now the get-descriptor is in sync with master and with separated implementation, which should minimize a chance of a conflict.
Great. At least now we can test using the get-descriptor branch which is in sync with the master.
@Youw Great work! Thank you! If I should do some tasks, please tell me. Otherwise I wait, to prevent conflicting work.
I never intended to include pp_data_dump into the main repo. Therefore it's just a quick and dirty implementation, where I never started a Pull-Request for. But if you want, I could clean this up and start a Pull-Request.
Pull request closed