RFC: add hid_get_report_descriptor API function #451

2022-09-10T11:27:41-05:00

Youw commented

2022-09-10 11:27:41 -05:00

(Migrated from github.com)

Add ASAN checks for utest/MSVC build;

Resolves: #249

- [x] Add [ASAN](https://docs.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170) checks for utest/MSVC build; Resolves: #249

DJm00n commented

2022-10-16 02:38:14 -05:00

(Migrated from github.com)

Hey @Youw! Nice PR!
Can you please give some information about limitations of this approach?

I wanted to test it with a bunch of game controllers that I have and prepare tests for them. How to generate those *_expected.rpt_desc files?

Hey @Youw! Nice PR! Can you please give some information about limitations of this approach? I wanted to test it with a bunch of game controllers that I have and prepare tests for them. How to generate those `*_expected.rpt_desc` files?

Youw commented

2022-10-16 03:27:07 -05:00

(Migrated from github.com)

The main discussion is under #249.
And @JoergAtGithub did most of the job. I believe he has a tool to generate rpt files in one of his branches.

The main discussion is under #249. And @JoergAtGithub did most of the job. I believe he has a tool to generate `rpt` files in one of his branches.

JoergAtGithub commented

2022-10-16 04:29:38 -05:00

(Migrated from github.com)

@DJm00n I just opened PR #467 for the pp_data_dump.exe tool, that others can find it.

There are basically 3 restrictions with this approach:

It depends on the undocumented preparsed data struct (if Microsoft once decide to change the declaration of this struct, it would stop working - we tested it on Win7, Win10 and Win11 and between these versions, there are no changes)
The reconstructed descriptor is logical identical to the orginal, but not byte-wise
for example

0x75, 0x08,        //   Report Size (8)
0x95, 0x06,        //   Report Count (6)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x08,        //   Report Size (8)
0x95, 0x06,        //   Report Count (6)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)

is logically the same as:

0x75, 0x08,        //   Report Size (8)
0x95, 0x06,        //   Report Count (6)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)

because the preparsed data contain only the logical relevant information, we can only assume, how it looked byte-wise

The preparsed data do not contain information about the padding bits, which:

fill the gaps between the used bits (the number of these constant bits is determined, but not the type - but it doesn't matter logically)
are appended at the end of the report. The HID test spec says only, that you shoul fill the remaining bits of the last byte with constant bit padding. But it doesn't prohibit to add more constant bytes at the end - the reconstrctor can only assume, that there are no unused constant bytes add the end of a report.

--
But there are also some specified syntax cases (https://github.com/libusb/hidapi/pull/343#issuecomment-1002301673), which I implemented, but couldn't test, due to lack on real-world devices.
BTW: https://github.com/abend0c1/hidrdd/tree/master/examples contains all report descriptor examples published by the HID group in encoded form. If someone could program these into an HID device and than run pp_data_dump.exe, we would have several edge cases covered in the test case.

@DJm00n I just opened PR #467 for the `pp_data_dump.exe` tool, that others can find it. There are basically 3 restrictions with this approach: 1. It depends on the undocumented preparsed data struct (if Microsoft once decide to change the declaration of this struct, it would stop working - we tested it on Win7, Win10 and Win11 and between these versions, there are no changes) 2. The reconstructed descriptor is logical identical to the orginal, but not byte-wise for example ``` 0x75, 0x08, // Report Size (8) 0x95, 0x06, // Report Count (6) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x75, 0x08, // Report Size (8) 0x95, 0x06, // Report Count (6) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) ``` is logically the same as: ``` 0x75, 0x08, // Report Size (8) 0x95, 0x06, // Report Count (6) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) ``` because the preparsed data contain only the logical relevant information, we can only assume, how it looked byte-wise 3. The preparsed data do not contain information about the padding bits, which: - fill the gaps between the used bits (the number of these constant bits is determined, but not the type - but it doesn't matter logically) - are appended at the end of the report. The HID test spec says only, that you shoul fill the remaining bits of the last byte with constant bit padding. But it doesn't prohibit to add more constant bytes at the end - the reconstrctor can only assume, that there are no unused constant bytes add the end of a report. -- But there are also some specified syntax cases (https://github.com/libusb/hidapi/pull/343#issuecomment-1002301673), which I implemented, but couldn't test, due to lack on real-world devices. BTW: https://github.com/abend0c1/hidrdd/tree/master/examples contains all report descriptor examples published by the HID group in encoded form. If someone could program these into an HID device and than run `pp_data_dump.exe`, we would have several edge cases covered in the test case.

👍 1

JoergAtGithub (Migrated from github.com) reviewed

2022-10-16 06:46:24 -05:00

hidtest/test.c

					
				@ -64,10 +64,48 @@ void print_device(struct hid_device_info *cur_dev) {

					printf("\n");

		printf("  Report Descriptor: Unable to open device by path\n");

```suggestion printf(" Report Descriptor: Unable to open device by path\n"); ```

JoergAtGithub (Migrated from github.com) reviewed

2022-10-17 17:26:44 -05:00

windows/test/hid_report_reconstructor_test.c

					
				@ -0,0 +539,4 @@

						}

						else {

							result = EXIT_FAILURE;

							fprintf(stderr, "Reconstructed Report Descriptor has different content than expected\n");

			result = EXIT_FAILURE;
			fprintf(stderr, "Reconstructed Report Descriptor has different content than expected\n");

```suggestion result = EXIT_FAILURE; fprintf(stderr, "Reconstructed Report Descriptor has different content than expected\n"); ```

JoergAtGithub (Migrated from github.com) reviewed

2022-10-17 17:27:09 -05:00

windows/test/hid_report_reconstructor_test.c

					
				@ -0,0 +544,4 @@

					}

					else {

						result = EXIT_FAILURE;

						fprintf(stderr, "Reconstructed Report Descriptor has different size: %zu when expected %zu\n", report_descriptor_size, expected_report_descriptor_size);

		result = EXIT_FAILURE;
		fprintf(stderr, "Reconstructed Report Descriptor has different size: %zu when expected %zu\n", report_descriptor_size, expected_report_descriptor_size);

```suggestion result = EXIT_FAILURE; fprintf(stderr, "Reconstructed Report Descriptor has different size: %zu when expected %zu\n", report_descriptor_size, expected_report_descriptor_size); ```

mcuee commented

2023-01-25 21:09:44 -06:00

(Migrated from github.com)

Just FYI of others that #343 and #467 have been integrated in the following feature branch.
https://github.com/libusb/hidapi/tree/get-descriptor

More test results here:

https://github.com/libusb/hidapi/issues/249

Just FYI of others that #343 and #467 have been integrated in the following feature branch. https://github.com/libusb/hidapi/tree/get-descriptor More test results here: * https://github.com/libusb/hidapi/issues/249

Youw (Migrated from github.com) reviewed

2023-02-22 05:16:28 -06:00

Youw (Migrated from github.com) left a comment

It has been a long way to get at this point.
Thanks everyone.

I'll keep this PR for a couple of days. If no objections/issues found - I'll merge it to master after that.

It has been a long way to get at this point. Thanks everyone. I'll keep this PR for a couple of days. If no objections/issues found - I'll merge it to master after that.

mcuee commented

2023-03-12 08:27:00 -05:00

(Migrated from github.com)