gh-libusb/hidapi
Watch
1
0
Fork
You've already forked hidapi
 0
Code Issues 58 Pull requests 18 Releases 13 Wiki Activity

Properly determine libusb read size for large reports (Fixes #274) #728

Open
sudobash1 wants to merge 16 commits from sudobash1/libusb_input_size into master
pull from: sudobash1/libusb_input_size
merge into: gh-libusb:master
Conversation 94 Commits 16 Files changed 6 +741 -8
sudobash1 commented 2025-03-25 15:27:04 -05:00 (Migrated from github.com)

Summary

  • Derive the libusb interrupt-IN transfer size from the HID report descriptor so reports larger than wMaxPacketSize are delivered whole.
  • Preserve wMaxPacketSize as the minimum buffer size for devices that pad short reports, and fall back to it when a descriptor cannot be read or parsed safely.
  • Cache successfully fetched report descriptors for hid_get_report_descriptor().
  • Bound descriptor-controlled report sizes, handle read-thread allocation/submission failures safely, and skip automatic report-descriptor requests for non-HID vendor interfaces.
  • Add cross-platform parser tests using all 25 Windows _real.rpt_desc fixtures plus malformed, overflow, Report ID, Push/Pop, long-item, and boundary cases.

Verification

  • GCC C build with -Wall -Wextra -pedantic -Werror: 26 runnable tests passed; hardware-only DeviceIO test skipped.
  • GCC C++ backend build with -Wall -Wextra -Werror: 26 runnable tests passed; hardware-only DeviceIO test skipped.
  • AddressSanitizer + UndefinedBehaviorSanitizer build: 26 runnable tests passed; hardware-only DeviceIO test skipped.
  • Modeled FreeBSD CMake configuration preserves HIDAPI_WITH_TESTS=ON and registers all 26 libusb tests.

Fixes #274

Related to #796

Related to #833

Assisted-by: codex:gpt-5.6-sol
Assisted-by: claude-code:claude-fable-5

## Summary - Derive the libusb interrupt-IN transfer size from the HID report descriptor so reports larger than `wMaxPacketSize` are delivered whole. - Preserve `wMaxPacketSize` as the minimum buffer size for devices that pad short reports, and fall back to it when a descriptor cannot be read or parsed safely. - Cache successfully fetched report descriptors for `hid_get_report_descriptor()`. - Bound descriptor-controlled report sizes, handle read-thread allocation/submission failures safely, and skip automatic report-descriptor requests for non-HID vendor interfaces. - Add cross-platform parser tests using all 25 Windows `_real.rpt_desc` fixtures plus malformed, overflow, Report ID, Push/Pop, long-item, and boundary cases. ## Verification - GCC C build with `-Wall -Wextra -pedantic -Werror`: 26 runnable tests passed; hardware-only DeviceIO test skipped. - GCC C++ backend build with `-Wall -Wextra -Werror`: 26 runnable tests passed; hardware-only DeviceIO test skipped. - AddressSanitizer + UndefinedBehaviorSanitizer build: 26 runnable tests passed; hardware-only DeviceIO test skipped. - Modeled FreeBSD CMake configuration preserves `HIDAPI_WITH_TESTS=ON` and registers all 26 libusb tests. Fixes #274 Related to #796 Related to #833 Assisted-by: codex:gpt-5.6-sol Assisted-by: claude-code:claude-fable-5
👍 1 ❤️ 1 🚀 1
JoergAtGithub (Migrated from github.com) reviewed 2025-03-25 15:27:04 -05:00
sudobash1 commented 2025-03-25 17:08:47 -05:00 (Migrated from github.com)

PR updated to remove different signedness comparison compiler warning when compiling with -Wall.

PR updated to remove different signedness comparison compiler warning when compiling with `-Wall`.
Be-ing commented 2025-03-25 20:07:51 -05:00 (Migrated from github.com)

Thank you for finally taking care of this longstanding bug.

Thank you for finally taking care of this longstanding bug.
Youw (Migrated from github.com) reviewed 2025-03-26 05:00:25 -05:00
Youw (Migrated from github.com) left a comment

Thanks for this, I'll perform a thorrow review a bit later.
@Be-ing can you confirm it fixes the issue with long reports too?

Thanks for this, I'll perform a thorrow review a bit later. @Be-ing can you confirm it fixes the issue with long reports too?
libusb/hid.c
Youw (Migrated from github.com) commented 2025-03-26 04:59:50 -05:00

lets make this conversion earlier, and store the value already in bytes

lets make this conversion earlier, and store the value already in bytes
JoergAtGithub (Migrated from github.com) reviewed 2025-03-26 13:21:26 -05:00
libusb/hid.c
JoergAtGithub (Migrated from github.com) commented 2025-03-26 13:21:25 -05:00

This function seems to be the functional the same as InputReportByteLength from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps on Windows.

We have a lot of test data for the Windows unit test, which stores the result of this function: github.com/libusb/hidapi@0ab6c14264/windows/test/data/045E_02FF_0005_0001.pp_data (L21)
together with the real ReportDescriptor https://github.com/libusb/hidapi/blob/master/windows/test/data/045E_02FF_0005_0001_real.rpt_desc

What do you think about creating a unit test for the new get_max_input_size function using the _real.rpt_desc files as input and compare the result with the value stored in the .pp_data.

This function seems to be the functional the same as `InputReportByteLength` from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps on Windows. We have a lot of test data for the Windows unit test, which stores the result of this function: https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/045E_02FF_0005_0001.pp_data#L21 together with the real ReportDescriptor https://github.com/libusb/hidapi/blob/master/windows/test/data/045E_02FF_0005_0001_real.rpt_desc What do you think about creating a unit test for the new `get_max_input_size` function using the `_real.rpt_desc` files as input and compare the result with the value stored in the `.pp_data`.
sudobash1 (Migrated from github.com) reviewed 2025-03-26 13:40:06 -05:00
libusb/hid.c
sudobash1 (Migrated from github.com) commented 2025-03-26 13:40:06 -05:00

Nice! That does look like a great dataset. I'll see if I can figure a clean way to make a unit test, and see how it fares with that data.

Currently the get_max_input_size is a static function, but I need a way to use it externally in the unit test. It seems that the windows library has some extensions prefixed with winapi. Should I rename the get max function to hid_libusbapi_get_max_input_report_size and mark it HID_API_EXPORT_CALL?

I will also need to change how it gets the report descriptor, but that won't be a problem.

Nice! That does look like a great dataset. I'll see if I can figure a clean way to make a unit test, and see how it fares with that data. Currently the `get_max_input_size` is a `static` function, but I need a way to use it externally in the unit test. It seems that the windows library has some extensions prefixed with `winapi`. Should I rename the get max function to `hid_libusbapi_get_max_input_report_size` and mark it `HID_API_EXPORT_CALL`? I will also need to change how it gets the report descriptor, but that won't be a problem.
Youw (Migrated from github.com) reviewed 2025-03-26 13:49:39 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2025-03-26 13:49:39 -05:00

Making it with HID_API_EXPORT_CALL would make it a public (at least on binary level) function, which is undesirable, if it is required for tests only. Maybe export it only when building unit-tests etc. or try to avoid it by using static linking or smth else (or have it in an internal header file?)

Making it with `HID_API_EXPORT_CALL` would make it a public (at least on binary level) function, which is undesirable, if it is required for tests only. Maybe export it only when building unit-tests etc. or try to avoid it by using static linking or smth else (or have it in an internal header file?)
JoergAtGithub (Migrated from github.com) reviewed 2025-03-26 13:50:37 -05:00
libusb/hid.c
JoergAtGithub (Migrated from github.com) commented 2025-03-26 13:50:37 -05:00

Have a look at the Windows unit test ( https://github.com/libusb/hidapi/tree/master/windows/test ) for the report descriptor reconstructor. There we had exactly the same challenges, hid_winapi_descriptor_reconstruct_pp_data was the internal function to test there.

Have a look at the Windows unit test ( https://github.com/libusb/hidapi/tree/master/windows/test ) for the report descriptor reconstructor. There we had exactly the same challenges, hid_winapi_descriptor_reconstruct_pp_data was the internal function to test there.
sudobash1 (Migrated from github.com) reviewed 2025-03-26 14:02:07 -05:00
libusb/hid.c
sudobash1 (Migrated from github.com) commented 2025-03-26 14:02:07 -05:00

@JoergAtGithub I did actually look at hid_winapi_descriptor_reconstruct_pp_data, and it is marked as HID_API_EXPORT_CALL in the header file:

github.com/libusb/hidapi@0ab6c14264/windows/hidapi_winapi.h (L68)

Although, now that I am looking, it is not marked in the C file:

github.com/libusb/hidapi@0ab6c14264/windows/hidapi_descriptor_reconstruct.c (L181)

WRT @Youw's suggestion. I could simplify the function a bit so that it doesn't depend on anything in hid.c and then move it to hid_max_input_report.h. If that is acceptable, it is probably the easiest solution.

@JoergAtGithub I did actually look at `hid_winapi_descriptor_reconstruct_pp_data`, and it is marked as `HID_API_EXPORT_CALL` in the header file: https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/hidapi_winapi.h#L68 Although, now that I am looking, it is not marked in the C file: https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/hidapi_descriptor_reconstruct.c#L181 WRT @Youw's suggestion. I could simplify the function a bit so that it doesn't depend on anything in `hid.c` and then move it to `hid_max_input_report.h`. If that is acceptable, it is probably the easiest solution.
Youw (Migrated from github.com) reviewed 2025-03-26 16:13:29 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2025-03-26 16:13:28 -05:00

hid_winapi_descriptor_reconstruct_pp_data, and it is marked as HID_API_EXPORT_CALL in the header file

Right - that is a public API function. That is also the reason why there is a winapi prefix in the name.

it is not marked in the C file

Not required, if it is marked in the header.

I could simplify the function a bit so that it doesn't depend on anything in hid.c and then move it to hid_max_input_report.h. If that is acceptable, it is probably the easiest solution.

Yes, sounds like simples solution for now. Go for it.

> hid_winapi_descriptor_reconstruct_pp_data, and it is marked as HID_API_EXPORT_CALL in the header file Right - that _is_ a public API function. That is also the reason why there is a `winapi` prefix in the name. > it is not marked in the C file Not required, if it is marked in the header. > I could simplify the function a bit so that it doesn't depend on anything in hid.c and then move it to hid_max_input_report.h. If that is acceptable, it is probably the easiest solution. Yes, sounds like simples solution for now. Go for it.
sudobash1 (Migrated from github.com) reviewed 2025-03-26 18:31:08 -05:00
libusb/hid.c
sudobash1 (Migrated from github.com) commented 2025-03-26 18:31:08 -05:00

I have a test, but it isn't passing. It could be that I am misunderstanding the Windows HID structures. I have only a vague understanding of them.

For example, in the 046A_0011_0006_0001 test data, it gives a max input size of 9 bytes:

github.com/libusb/hidapi@0ab6c14264/windows/test/data/046A_0011_0006_0001.pp_data (L16-L19)

But two input caps (cap[0] and cap[1]) are:

github.com/libusb/hidapi@0ab6c14264/windows/test/data/046A_0011_0006_0001.pp_data (L37-L38)

github.com/libusb/hidapi@0ab6c14264/windows/test/data/046A_0011_0006_0001.pp_data (L83-L84)

According to the documentation I read, the report size is just BitSize * ReportCount (plus a byte for the report number I assume).

This gives report sizes of (1*8)/8 + 1 = 2 and (8*6)/8 + 1 = 7. So I don't know where the ReportByteLength = 9 value is coming from.

Do either of you know what I am missing here?

I have a test, but it isn't passing. It could be that I am misunderstanding the Windows HID structures. I have only a vague understanding of them. For example, in the `046A_0011_0006_0001` test data, it gives a max input size of 9 bytes: https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/046A_0011_0006_0001.pp_data#L16-L19 But two input caps (`cap[0]` and `cap[1]`) are: https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/046A_0011_0006_0001.pp_data#L37-L38 https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/046A_0011_0006_0001.pp_data#L83-L84 According to the [documentation I read](https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/interpreting-hid-reports#extracting-value-data-by-specifying-its-usage), the report size is just `BitSize * ReportCount` (plus a byte for the report number I assume). This gives report sizes of `(1*8)/8 + 1 = 2` and `(8*6)/8 + 1 = 7`. So I don't know where the `ReportByteLength = 9` value is coming from. Do either of you know what I am missing here?
mcuee commented 2025-03-27 00:12:38 -05:00 (Migrated from github.com)

BTW, there is a typo here.
@Youw and @JoergAtGithub.
github.com/libusb/hidapi@0ab6c14264/windows/test/data/046A_0011_0006_0001.pp_data (L4)

dev->manufacturer_string = "dev->product_string      = "dev->release_number      = 0x0100
BTW, there is a typo here. @Youw and @JoergAtGithub. https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/046A_0011_0006_0001.pp_data#L4 ``` dev->manufacturer_string = "dev->product_string = "dev->release_number = 0x0100 ```
JoergAtGithub commented 2025-03-27 01:17:16 -05:00 (Migrated from github.com)

I put 046A_0011_0006_0001_real.rpt_desc into https://eleccelerator.com/usbdescreqparser/ and got:

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x06,        // Usage (Keyboard)
0xA1, 0x01,        // Collection (Application)
0x05, 0x07,        //   Usage Page (Kbrd/Keypad)
0x19, 0xE0,        //   Usage Minimum (0xE0)
0x29, 0xE7,        //   Usage Maximum (0xE7)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x08,        //   Report Count (8)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x08,        //   Report Size (8)
0x95, 0x01,        //   Report Count (1)
0x81, 0x03,        //   Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x19, 0x00,        //   Usage Minimum (0x00)
0x29, 0xDD,        //   Usage Maximum (0xDD)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xDD, 0x00,  //   Logical Maximum (221)
0x75, 0x08,        //   Report Size (8)
0x95, 0x06,        //   Report Count (6)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x08,        //   Usage Page (LEDs)
0x19, 0x01,        //   Usage Minimum (Num Lock)
0x29, 0x03,        //   Usage Maximum (Scroll Lock)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x03,        //   Report Count (3)
0x91, 0x02,        //   Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x75, 0x05,        //   Report Size (5)
0x95, 0x01,        //   Report Count (1)
0x91, 0x03,        //   Output (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              // End Collection

The InputReport contains:

  • 8x1bit data
  • 1x8bit constant padding
  • 6x8bit data
    This sums to 8byte, but InputReportByteLength is defined as follows:
    Specifies the maximum size, in bytes, of all the input reports. Includes the report ID, which is prepended to the report data. If report ID is not used, the ID value is zero.
    So we've to add a byte for the ReportID and are at 9 bytes.
I put `046A_0011_0006_0001_real.rpt_desc` into https://eleccelerator.com/usbdescreqparser/ and got: ``` 0x05, 0x01, // Usage Page (Generic Desktop Ctrls) 0x09, 0x06, // Usage (Keyboard) 0xA1, 0x01, // Collection (Application) 0x05, 0x07, // Usage Page (Kbrd/Keypad) 0x19, 0xE0, // Usage Minimum (0xE0) 0x29, 0xE7, // Usage Maximum (0xE7) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x08, // Report Count (8) 0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x75, 0x08, // Report Size (8) 0x95, 0x01, // Report Count (1) 0x81, 0x03, // Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x19, 0x00, // Usage Minimum (0x00) 0x29, 0xDD, // Usage Maximum (0xDD) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xDD, 0x00, // Logical Maximum (221) 0x75, 0x08, // Report Size (8) 0x95, 0x06, // Report Count (6) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x05, 0x08, // Usage Page (LEDs) 0x19, 0x01, // Usage Minimum (Num Lock) 0x29, 0x03, // Usage Maximum (Scroll Lock) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x03, // Report Count (3) 0x91, 0x02, // Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x75, 0x05, // Report Size (5) 0x95, 0x01, // Report Count (1) 0x91, 0x03, // Output (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0xC0, // End Collection ``` The InputReport contains: - 8x1bit data - 1x8bit constant padding - 6x8bit data This sums to 8byte, but `InputReportByteLength` is defined as follows: _Specifies the maximum size, in bytes, of all the input reports. Includes the report ID, which is prepended to the report data. If report ID is not used, the ID value is zero._ So we've to add a byte for the ReportID and are at 9 bytes.
👍 1
JoergAtGithub commented 2025-03-27 01:20:44 -05:00 (Migrated from github.com)

BTW, there is a typo here. @Youw and @JoergAtGithub.

github.com/libusb/hidapi@0ab6c14264/windows/test/data/046A_0011_0006_0001.pp_data (L4)

dev->manufacturer_string = "dev->product_string      = "dev->release_number      = 0x0100

There is something missing, as this is autogenerated by pp_data_dump, I guess there was something in the manufacturer_string , that pp_data_dump couldn't handle. Could you please open a dedicated issue for this, as this is unrelated to this PR.

> BTW, there is a typo here. @Youw and @JoergAtGithub. > > https://github.com/libusb/hidapi/blob/0ab6c14264ec76e9328a8eedb3b72b5d27dffd47/windows/test/data/046A_0011_0006_0001.pp_data#L4 > > ``` > dev->manufacturer_string = "dev->product_string = "dev->release_number = 0x0100 > ``` There is something missing, as this is autogenerated by pp_data_dump, I guess there was something in the manufacturer_string , that pp_data_dump couldn't handle. Could you please open a dedicated issue for this, as this is unrelated to this PR.
👍 1
mcuee commented 2025-03-27 02:34:55 -05:00 (Migrated from github.com)

There is something missing, as this is autogenerated by pp_data_dump, I guess there was something in the manufacturer_string , that pp_data_dump couldn't handle. Could you please open a dedicated issue for this, as this is unrelated to this PR.

> There is something missing, as this is autogenerated by pp_data_dump, I guess there was something in the manufacturer_string , that pp_data_dump couldn't handle. Could you please open a dedicated issue for this, as this is unrelated to this PR. * https://github.com/libusb/hidapi/issues/729
JoergAtGithub (Migrated from github.com) requested changes 2025-03-27 14:49:35 -05:00
libusb/hid.c
JoergAtGithub (Migrated from github.com) commented 2025-03-27 14:49:30 -05:00 
			if (report_count < 0 || report_size < 0) {
				/* We are missing size or count. That isn't good. */
				return -1;

This would mean a corrupt ReportDescriptor

```suggestion if (report_count < 0 || report_size < 0) { /* We are missing size or count. That isn't good. */ return -1; ``` This would mean a corrupt ReportDescriptor
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
JoergAtGithub (Migrated from github.com) commented 2025-03-27 14:48:22 -05:00

You need to parse the _real.rpt_desc, not the _expected.rpt_desc. The real is what is dumped from the device, and the expected is what the Windows ReportDescriptor-Reconstructor generates out of the .pp_data.

You need to parse the `_real.rpt_desc`, not the `_expected.rpt_desc`. The real is what is dumped from the device, and the expected is what the Windows ReportDescriptor-Reconstructor generates out of the .pp_data.
sudobash1 (Migrated from github.com) reviewed 2025-03-27 14:57:03 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
sudobash1 (Migrated from github.com) commented 2025-03-27 14:57:03 -05:00

I see. I assumed that the real and expected should contain equivalent reports.

The _real.rpt_desc files do not follow a consistent format, so should I parse them manually (should be pretty doable with a bit of regex) into new files and add them to the repo?

I see. I assumed that the `real` and `expected` should contain equivalent reports. The `_real.rpt_desc` files do not follow a consistent format, so should I parse them manually (should be pretty doable with a bit of regex) into new files and add them to the repo?
sudobash1 (Migrated from github.com) reviewed 2025-03-27 14:59:57 -05:00
libusb/hid.c
sudobash1 (Migrated from github.com) commented 2025-03-27 14:59:57 -05:00

I wasn't consistent with whether I was using size_t or ssize_t. In my last commit, I settled on size_t, but perhaps I should change it back to ssize_t so that we can more clearly differentiate between errors and a zero value (if there are no feature reports, it will return 0, which is not an error).

I wasn't consistent with whether I was using `size_t` or `ssize_t`. In my last commit, I settled on `size_t`, but perhaps I should change it back to `ssize_t` so that we can more clearly differentiate between errors and a zero value (if there are no feature reports, it will return 0, which is not an error).
sudobash1 commented 2025-03-27 15:00:14 -05:00 (Migrated from github.com)

Thanks @JoergAtGithub for walking me through that. I was misreading the descriptor.

I have added tests for libusb using the same data as the windows tests. And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available.

Thanks @JoergAtGithub for walking me through that. I was misreading the descriptor. I have added tests for libusb using the same data as the windows tests. And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available.
JoergAtGithub (Migrated from github.com) reviewed 2025-03-27 15:00:34 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
JoergAtGithub (Migrated from github.com) commented 2025-03-27 15:00:34 -05:00

Maybe you can put them into https://eleccelerator.com/usbdescreqparser/ to unify the format. That makes them also human readable.

Maybe you can put them into https://eleccelerator.com/usbdescreqparser/ to unify the format. That makes them also human readable.
JoergAtGithub commented 2025-03-27 15:10:00 -05:00 (Migrated from github.com)

And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available.

Independent of this PR, I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values InputReportByteLength, OutputReportByteLength and FeatureReportByteLength from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows.
In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms. @Youw What do you think about this?

> And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available. Independent of this PR, I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values `InputReportByteLength`, `OutputReportByteLength` and `FeatureReportByteLength` from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows. In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms. @Youw What do you think about this?
👍 1
JoergAtGithub (Migrated from github.com) reviewed 2025-03-27 15:18:12 -05:00
libusb/hid.c
JoergAtGithub (Migrated from github.com) commented 2025-03-27 15:18:12 -05:00

Makes sense!

Makes sense!
sudobash1 (Migrated from github.com) reviewed 2025-03-27 15:21:05 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
sudobash1 (Migrated from github.com) commented 2025-03-27 15:21:05 -05:00

Good idea.

Good idea.
Youw (Migrated from github.com) reviewed 2025-03-28 05:31:54 -05:00
CMakeLists.txt
Youw (Migrated from github.com) commented 2025-03-28 05:31:54 -05:00

also need to update builds.yml

also need to update [builds.yml](https://github.com/libusb/hidapi/blob/master/.github/workflows/builds.yml)
Youw (Migrated from github.com) reviewed 2025-03-28 05:34:48 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
Youw (Migrated from github.com) commented 2025-03-28 05:34:48 -05:00
```suggestion ```
Youw (Migrated from github.com) reviewed 2025-03-28 05:35:38 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +43,4 @@
)
foreach(TEST_CASE ${HID_REPORT_DESCRIPTOR_TEST_CASES})
set(TEST_PP_DATA "${CMAKE_CURRENT_LIST_DIR}/../../windows/test/data/${TEST_CASE}.pp_data")
Youw (Migrated from github.com) commented 2025-03-28 05:35:37 -05:00

maybe move the test data to <root>/test_data ?

maybe move the test data to `<root>/test_data` ?
Youw (Migrated from github.com) reviewed 2025-03-28 05:37:28 -05:00
Youw (Migrated from github.com) left a comment

I don't have a strong opinion on test implementation (I trust @JoergAtGithub on this one).
libusb implementation seem fine.

Lets make sure it runs with CI on Github Actions and we're good to go here.

I don't have a strong opinion on test implementation (I trust @JoergAtGithub on this one). libusb implementation seem fine. Lets make sure it runs with CI on Github Actions and we're good to go here.
Youw commented 2025-03-28 05:39:49 -05:00 (Migrated from github.com)

And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available.

Independent of this PR, I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values InputReportByteLength, OutputReportByteLength and FeatureReportByteLength from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows. In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms. @Youw What do you think about this?

Lets continue here: https://github.com/libusb/hidapi/issues/731

> > And I extended the functionality of the libusb method to be able to calculate the maximum output and feature report sizes as well. This has no functional use currently, but it lets us run three times as many tests since the pp_data files have all three max sizes available. > > Independent of this PR, I think it would generally make sense to store these 3 values in the device structure. On Windows we would have to use the values `InputReportByteLength`, `OutputReportByteLength` and `FeatureReportByteLength` from https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps . On all other backends we could use your parser to determine them - and with the testcase you proved that they are the same as on Windows. In this way, we were able to programmatically determine the required buffer sizes for read/write operations on all platforms. @Youw What do you think about this? Lets continue here: https://github.com/libusb/hidapi/issues/731
mcuee commented 2025-03-28 09:46:09 -05:00 (Migrated from github.com)

This PR does not seem to work.

Test device is the same as the one used in Issue #274. The FW is a mod of Jan Axelson's FX2HID example and codes are included in the following #274 comment.

I can reproduce the issue reported in #274 with hidapi git libusb backend, hidraw backend is okay.

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading 129-byte input report 0, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading 129-byte input report 0, 250 msec timeout...read 64 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

With this PR, no change in hidraw backend behavior, which is good.

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading 129-byte input report 0, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

But the libusb backend fix is not working.

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ make -f Makefile_pr728.libusb 
cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi -c ../hidapi_pr728/libusb/hid.c -o ../hidapi_pr728/libusb/hid.o
cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi -c hidapitester.c -o hidapitester.o
cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi ../hidapi_pr728/libusb/hid.o hidapitester.o -o hidapitester -L/usr/local/lib -lusb-1.0 -pthread

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ mv hidapitester hidapitester_libusb_pr728 

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 128 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 128-bytes...wrote 128 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
Reading 128-byte input report 0, 250 msec timeout...read 0 bytes:
Closing device
This PR does not seem to work. Test device is the same as the one used in Issue #274. The FW is a mod of Jan Axelson's FX2HID example and codes are included in the following #274 comment. * https://github.com/libusb/hidapi/issues/274#issuecomment-1547968118 I can reproduce the issue reported in #274 with hidapi git libusb backend, hidraw backend is okay. ``` mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading 129-byte input report 0, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading 129-byte input report 0, 250 msec timeout...read 64 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device ``` With this PR, no change in hidraw backend behavior, which is good. ``` mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading 129-byte input report 0, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ``` But the libusb backend fix is not working. ``` mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ make -f Makefile_pr728.libusb cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi -c ../hidapi_pr728/libusb/hid.c -o ../hidapi_pr728/libusb/hid.o cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi -c hidapitester.c -o hidapitester.o cc -I/usr/local/include/libusb-1.0 -I ../hidapi_pr728/hidapi ../hidapi_pr728/libusb/hid.o hidapitester.o -o hidapitester -L/usr/local/lib -lusb-1.0 -pthread mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ mv hidapitester hidapitester_libusb_pr728 mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 128 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 128-bytes...wrote 128 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F Reading 128-byte input report 0, 250 msec timeout...read 0 bytes: Closing device ```
mcuee commented 2025-03-28 09:50:44 -05:00 (Migrated from github.com)

HID Report Descriptor.

ReportDscr:

	db 06h, 0A0h, 0FFh ;    Usage Page (FFA0h, vendor defined)
	db 09h, 01h     ;       Usage (vendor defined)
	db 0A1h, 01h    ;       Collection (Application)
	db 09h, 02h     ;       Usage (vendor defined)
	db 0A1h, 00h    ;       Collection (Physical)
	db 06h, 0A1h, 0FFh ;    Usage Page (vendor defined)

;; The Input report
	db 09h, 03h     ;       Usage (vendor defined)
	db 09h, 04h     ;       Usage (vendor defined)
	db 15h, 80h	;	Logical minimum (80h or -128)
	db 25h, 7Fh	;	Logical maximum (7Fh or 127)
	db 35h, 00h	;	Physical minimum (0)
	db 45h, 0FFh	;	Physical maximum (255)
	db 75h, 08h	;	Report size (8 bits)
	db 95h, 80h	;	Report count (128 fields)
	db 81h, 02h	;	Input (data, variable, absolute)

;; The Output report
	db 09h, 05h     ;       Usage (vendor defined)
	db 09h, 06h     ;       Usage (vendor defined)
	db 15h, 80h	;	Logical minimum (80h or -128)
	db 25h, 7Fh	;	Logical maximum (7Fh or 127)
	db 35h, 00h	;	Physical minimum (0)
	db 45h, 0FFh	;	Physical maximum (255)
	db 75h, 08h	;	Report size (8 bits)
	db 95h, 80h	;	Report count (128 fields)
	db 91h, 02h	;	Output (data, variable, absolute)

	db 0C0h         ;       End Collection (Physical)
	db 0C0h         ;       End Collection (Application)

ReportDscrEnd:

hidtest is okay.

mcuee@UbuntuSwift3 ~/build/hid/hidapi (master)$ sudo ./hidtest/hidtest-libusb 
hidapi test/example tool. Compiled with hidapi version 0.15.0, runtime version 0.15.0.
Compile-time version matches runtime version of hidapi.

Device Found
  type: 0925 1234
  path: 3-2.1:1.0
  serial_number: (null)
  Manufacturer: CYPRESS
  Product:      EZ-USB FX2 HID USBHIDIO
  Release:      0
  Interface:    0
  Usage (page): 0x0 (0x0)
  Bus type: 1 (USB)

  Report Descriptor: (52 bytes)
0x06, 0xa0, 0xff, 0x09, 0x01, 0xa1, 0x01, 0x09, 0x02, 0xa1, 
0x00, 0x06, 0xa1, 0xff, 0x09, 0x03, 0x09, 0x04, 0x15, 0x80, 
0x25, 0x7f, 0x35, 0x00, 0x45, 0xff, 0x75, 0x08, 0x95, 0x80, 
0x81, 0x02, 0x09, 0x05, 0x09, 0x06, 0x15, 0x80, 0x25, 0x7f, 
0x35, 0x00, 0x45, 0xff, 0x75, 0x08, 0x95, 0x80, 0x91, 0x02, 
0xc0, 0xc0, 
unable to open device
HID Report Descriptor. ``` ReportDscr: db 06h, 0A0h, 0FFh ; Usage Page (FFA0h, vendor defined) db 09h, 01h ; Usage (vendor defined) db 0A1h, 01h ; Collection (Application) db 09h, 02h ; Usage (vendor defined) db 0A1h, 00h ; Collection (Physical) db 06h, 0A1h, 0FFh ; Usage Page (vendor defined) ;; The Input report db 09h, 03h ; Usage (vendor defined) db 09h, 04h ; Usage (vendor defined) db 15h, 80h ; Logical minimum (80h or -128) db 25h, 7Fh ; Logical maximum (7Fh or 127) db 35h, 00h ; Physical minimum (0) db 45h, 0FFh ; Physical maximum (255) db 75h, 08h ; Report size (8 bits) db 95h, 80h ; Report count (128 fields) db 81h, 02h ; Input (data, variable, absolute) ;; The Output report db 09h, 05h ; Usage (vendor defined) db 09h, 06h ; Usage (vendor defined) db 15h, 80h ; Logical minimum (80h or -128) db 25h, 7Fh ; Logical maximum (7Fh or 127) db 35h, 00h ; Physical minimum (0) db 45h, 0FFh ; Physical maximum (255) db 75h, 08h ; Report size (8 bits) db 95h, 80h ; Report count (128 fields) db 91h, 02h ; Output (data, variable, absolute) db 0C0h ; End Collection (Physical) db 0C0h ; End Collection (Application) ReportDscrEnd: ``` hidtest is okay. ``` mcuee@UbuntuSwift3 ~/build/hid/hidapi (master)$ sudo ./hidtest/hidtest-libusb hidapi test/example tool. Compiled with hidapi version 0.15.0, runtime version 0.15.0. Compile-time version matches runtime version of hidapi. Device Found type: 0925 1234 path: 3-2.1:1.0 serial_number: (null) Manufacturer: CYPRESS Product: EZ-USB FX2 HID USBHIDIO Release: 0 Interface: 0 Usage (page): 0x0 (0x0) Bus type: 1 (USB) Report Descriptor: (52 bytes) 0x06, 0xa0, 0xff, 0x09, 0x01, 0xa1, 0x01, 0x09, 0x02, 0xa1, 0x00, 0x06, 0xa1, 0xff, 0x09, 0x03, 0x09, 0x04, 0x15, 0x80, 0x25, 0x7f, 0x35, 0x00, 0x45, 0xff, 0x75, 0x08, 0x95, 0x80, 0x81, 0x02, 0x09, 0x05, 0x09, 0x06, 0x15, 0x80, 0x25, 0x7f, 0x35, 0x00, 0x45, 0xff, 0x75, 0x08, 0x95, 0x80, 0x91, 0x02, 0xc0, 0xc0, unable to open device ```
sudobash1 commented 2025-03-29 13:20:37 -05:00 (Migrated from github.com)

If I have time, I'll try to address @JoergAtGithub and @Youw's comments on Monday.

@mcuee I tried feeding the report descriptor that you sent into get_max_report_size and it returned 129, which seems correct. I'll try to look into this on Monday as well.

I did notice a typo in your test. When you ran ./hidapitester_libusb_pr728, you specified -l 128 which should have been -l 129, but I think it should have returned data anyway.

If I have time, I'll try to address @JoergAtGithub and @Youw's comments on Monday. @mcuee I tried feeding the report descriptor that you sent into `get_max_report_size` and it returned `129`, which seems correct. I'll try to look into this on Monday as well. I did notice a typo in your test. When you ran `./hidapitester_libusb_pr728`, you specified `-l 128` which should have been `-l 129`, but I think it should have returned data anyway.
👍 1
mcuee commented 2025-03-29 19:19:38 -05:00 (Migrated from github.com)

Let me try again.

mcuee@UbuntuSwift3 ~/build/cyusb/fxload_libusb (master)$ sudo ./fxload -v -t fx2lp -I ./fx2hid.hex -D /dev/bus/usb/003/019 
microcontroller type: fx2lp
single stage:  load on-chip memory
open RAM hexfile image ./fx2hid.hex
stop CPU
write on-chip, addr 0x0600 len  234 (0x00ea)
write on-chip, addr 0x09e5 len   10 (0x000a)
write on-chip, addr 0x0380 len  428 (0x01ac)
write on-chip, addr 0x0080 len  768 (0x0300)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x09ff len    7 (0x0007)
write on-chip, addr 0x07b8 len   92 (0x005c)
write on-chip, addr 0x0851 len   59 (0x003b)
write on-chip, addr 0x05fe len    2 (0x0002)
write on-chip, addr 0x0a07 len    4 (0x0004)
write on-chip, addr 0x09ef len    8 (0x0008)
write on-chip, addr 0x09b0 len   18 (0x0012)
write on-chip, addr 0x09f7 len    8 (0x0008)
write on-chip, addr 0x09c2 len   18 (0x0012)
write on-chip, addr 0x0a0b len    6 (0x0006)
write on-chip, addr 0x091d len   40 (0x0028)
write on-chip, addr 0x096a len   24 (0x0018)
write on-chip, addr 0x06ea len   22 (0x0016)
write on-chip, addr 0x099a len   22 (0x0016)
write on-chip, addr 0x088c len   54 (0x0036)
write on-chip, addr 0x0982 len   24 (0x0018)
write on-chip, addr 0x0814 len   61 (0x003d)
write on-chip, addr 0x0a11 len   36 (0x0024)
write on-chip, addr 0x08f1 len   44 (0x002c)
write on-chip, addr 0x08c2 len   47 (0x002f)
write on-chip, addr 0x0945 len   20 (0x0014)
write on-chip, addr 0x05b8 len   70 (0x0046)
write on-chip, addr 0x0959 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x0700 len  184 (0x00b8)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x052c len   12 (0x000c)
write on-chip, addr 0x09d4 len   17 (0x0011)
write on-chip, addr 0x0538 len  128 (0x0080)
write on-chip, addr 0x0a06 len    1 (0x0001)
... WROTE: 2497 bytes, 36 segments, avg 69
reset CPU

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input 
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading 129-byte input report 0, 250 msec timeout...read 0 bytes:
Closing device

mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input 
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading 129-byte input report 0, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device
Let me try again. ``` mcuee@UbuntuSwift3 ~/build/cyusb/fxload_libusb (master)$ sudo ./fxload -v -t fx2lp -I ./fx2hid.hex -D /dev/bus/usb/003/019 microcontroller type: fx2lp single stage: load on-chip memory open RAM hexfile image ./fx2hid.hex stop CPU write on-chip, addr 0x0600 len 234 (0x00ea) write on-chip, addr 0x09e5 len 10 (0x000a) write on-chip, addr 0x0380 len 428 (0x01ac) write on-chip, addr 0x0080 len 768 (0x0300) write on-chip, addr 0x0033 len 3 (0x0003) write on-chip, addr 0x09ff len 7 (0x0007) write on-chip, addr 0x07b8 len 92 (0x005c) write on-chip, addr 0x0851 len 59 (0x003b) write on-chip, addr 0x05fe len 2 (0x0002) write on-chip, addr 0x0a07 len 4 (0x0004) write on-chip, addr 0x09ef len 8 (0x0008) write on-chip, addr 0x09b0 len 18 (0x0012) write on-chip, addr 0x09f7 len 8 (0x0008) write on-chip, addr 0x09c2 len 18 (0x0012) write on-chip, addr 0x0a0b len 6 (0x0006) write on-chip, addr 0x091d len 40 (0x0028) write on-chip, addr 0x096a len 24 (0x0018) write on-chip, addr 0x06ea len 22 (0x0016) write on-chip, addr 0x099a len 22 (0x0016) write on-chip, addr 0x088c len 54 (0x0036) write on-chip, addr 0x0982 len 24 (0x0018) write on-chip, addr 0x0814 len 61 (0x003d) write on-chip, addr 0x0a11 len 36 (0x0024) write on-chip, addr 0x08f1 len 44 (0x002c) write on-chip, addr 0x08c2 len 47 (0x002f) write on-chip, addr 0x0945 len 20 (0x0014) write on-chip, addr 0x05b8 len 70 (0x0046) write on-chip, addr 0x0959 len 17 (0x0011) write on-chip, addr 0x0043 len 3 (0x0003) write on-chip, addr 0x0053 len 3 (0x0003) write on-chip, addr 0x0700 len 184 (0x00b8) write on-chip, addr 0x0000 len 3 (0x0003) write on-chip, addr 0x052c len 12 (0x000c) write on-chip, addr 0x09d4 len 17 (0x0011) write on-chip, addr 0x0538 len 128 (0x0080) write on-chip, addr 0x0a06 len 1 (0x0001) ... WROTE: 2497 bytes, 36 segments, avg 69 reset CPU mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading 129-byte input report 0, 250 msec timeout...read 0 bytes: Closing device mcuee@UbuntuSwift3 ~/build/hid/hidapitester (master)$ sudo ./hidapitester_hidraw_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading 129-byte input report 0, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ```
mcuee commented 2025-03-29 22:11:55 -05:00 (Migrated from github.com)

Same problem under FreeBSD 14.1 Release.

This is with a physical machine, Chuwi mini PC, Intel J4125 CPU, 8GB/256GB configuration.

Without this PR, hidapi git has the problem mentioned in #274.

But then somehow this PR does not work.

mcuee@freebsd14:~/build/hidapi_pr730 $ uname -a
FreeBSD freebsd14 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64

mcuee@freebsd14:~ $ sudo lsusb
Bus /dev/usb Device /dev/ugen0.5: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. 
Bus /dev/usb Device /dev/ugen0.4: ID 13d3:3503 IMC Networks 
Bus /dev/usb Device /dev/ugen0.3: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4GHz Wireless rechargeable vertical mouse [More&Better]
Bus /dev/usb Device /dev/ugen0.2: ID 04f2:0760 Chicony Electronics Co., Ltd Acer KU-0760 Keyboard
Bus /dev/usb Device /dev/ugen0.1: ID 0000:0000  

mcuee@freebsd14:~/build/hidapi_pr730 $ fxload 
no device specified!
usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp, fx3
... at least one of -I, -L, -m is required

mcuee@freebsd14:~/build/hidapi_pr730 $ fxload -t fx2lp -I ./fx2hid.hex -D vid=0x04b4,pid=0x8613

mcuee@freebsd14:~/build/hidapi_pr730 $ lsusb
Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. 

mcuee@freebsd14:~/build/hidapi_pr730 $ sudo chmod 666 /dev/ugen0.5

mcuee@freebsd14:~/build/hidapi_pr730 $ lsusb
Bus /dev/usb Device /dev/ugen0.5: ID 0925:1234 Lakeview Research 
Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. 

mcuee@freebsd14:~/build/hidapitester $ ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

mcuee@freebsd14:~/build/hidapitester $ ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 0 bytes:
Closing device
Same problem under FreeBSD 14.1 Release. This is with a physical machine, Chuwi mini PC, Intel J4125 CPU, 8GB/256GB configuration. Without this PR, hidapi git has the problem mentioned in #274. But then somehow this PR does not work. ``` mcuee@freebsd14:~/build/hidapi_pr730 $ uname -a FreeBSD freebsd14 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 mcuee@freebsd14:~ $ sudo lsusb Bus /dev/usb Device /dev/ugen0.5: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. Bus /dev/usb Device /dev/ugen0.4: ID 13d3:3503 IMC Networks Bus /dev/usb Device /dev/ugen0.3: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4GHz Wireless rechargeable vertical mouse [More&Better] Bus /dev/usb Device /dev/ugen0.2: ID 04f2:0760 Chicony Electronics Co., Ltd Acer KU-0760 Keyboard Bus /dev/usb Device /dev/ugen0.1: ID 0000:0000 mcuee@freebsd14:~/build/hidapi_pr730 $ fxload no device specified! usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath] [-I firmware_hexfile] [-s loader] [-c config_byte] [-L link] [-m mode] ... [-D devpath] overrides DEVICE= in env ... device types: one of an21, fx, fx2, fx2lp, fx3 ... at least one of -I, -L, -m is required mcuee@freebsd14:~/build/hidapi_pr730 $ fxload -t fx2lp -I ./fx2hid.hex -D vid=0x04b4,pid=0x8613 mcuee@freebsd14:~/build/hidapi_pr730 $ lsusb Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. mcuee@freebsd14:~/build/hidapi_pr730 $ sudo chmod 666 /dev/ugen0.5 mcuee@freebsd14:~/build/hidapi_pr730 $ lsusb Bus /dev/usb Device /dev/ugen0.5: ID 0925:1234 Lakeview Research Bus /dev/usb Device /dev/ugen0.6: ID 04d8:003f Microchip Technology, Inc. mcuee@freebsd14:~/build/hidapitester $ ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device mcuee@freebsd14:~/build/hidapitester $ ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 0 bytes: Closing device ```
mcuee commented 2025-03-31 19:01:36 -05:00 (Migrated from github.com)

If I use the original fx2hid example (loop back of two bytes output report and input report), it seems to me this PR works fine. But that just means this PR has no regression.
http://janaxelson.com/hidpage.htm
http://janaxelson.com/files/fx2hid.zip

mcuee@freebsd14:~/build/hidapitester $ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 3-bytes...wrote 3 bytes:
 00 01 02
Reading up to 3-byte input report, 250 msec timeout...read 2 bytes:
 01 02 00
Closing device

mcuee@freebsd14:~/build/hidapitester $ sudo ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 3-bytes...wrote 3 bytes:
 00 01 02
Reading up to 3-byte input report, 250 msec timeout...read 2 bytes:
 01 02 00
Closing device
If I use the original fx2hid example (loop back of two bytes output report and input report), it seems to me this PR works fine. But that just means this PR has no regression. http://janaxelson.com/hidpage.htm http://janaxelson.com/files/fx2hid.zip ``` mcuee@freebsd14:~/build/hidapitester $ sudo ./hidapitester_libusb_pr728 --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 3-bytes...wrote 3 bytes: 00 01 02 Reading up to 3-byte input report, 250 msec timeout...read 2 bytes: 01 02 00 Closing device mcuee@freebsd14:~/build/hidapitester $ sudo ./hidapitester_libusb_git --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 3-bytes...wrote 3 bytes: 00 01 02 Reading up to 3-byte input report, 250 msec timeout...read 2 bytes: 01 02 00 Closing device ```
mcuee commented 2025-04-01 00:13:46 -05:00 (Migrated from github.com)

Just want to make sure the FW works fine, here is the test under Windows (native Windows HID backend).

Original fx2hid FW.

C:\work\libusb\hidapitester [main ≡ +6 ~0 -0 !]> .\hidapitester.exe --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 3-bytes...wrote 3 bytes:
 00 01 02
Reading up to 3-byte input report, 250 msec timeout...read 2 bytes:
 01 02 00
Closing device

My mod fx2hid FW (128 bytes report).

C:\work\libusb\hidapitester [main ≡ +6 ~0 -0 !]> .\hidapitester.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device
Just want to make sure the FW works fine, here is the test under Windows (native Windows HID backend). Original fx2hid FW. ``` C:\work\libusb\hidapitester [main ≡ +6 ~0 -0 !]> .\hidapitester.exe --vidpid 0925:1234 --open --buflen 3 -l 3 --send-output 0,1,2 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 3-bytes...wrote 3 bytes: 00 01 02 Reading up to 3-byte input report, 250 msec timeout...read 2 bytes: 01 02 00 Closing device ``` My mod fx2hid FW (128 bytes report). ``` C:\work\libusb\hidapitester [main ≡ +6 ~0 -0 !]> .\hidapitester.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ```
mcuee commented 2025-04-01 20:38:36 -05:00 (Migrated from github.com)

@Be-ing and @JoergAtGithub

Just wondering if you can carry out the test using your test device with long reports as well. Thanks.

@Be-ing and @JoergAtGithub Just wondering if you can carry out the test using your test device with long reports as well. Thanks.
mcuee commented 2025-04-01 20:49:20 -05:00 (Migrated from github.com)

@sudobash1

Just wondering which test device you are using. Thanks.

I am using two test devices, one is a simple EZ-USB FX2LP board which is pretty cheap from many places.
ez_usb_fx2lp_cy7c68013a_usb_development_board_3

The other is a very old Microchip USB demo board (PIC18F87J50 PIM), not worth buying now.
518-ma180021

@sudobash1 Just wondering which test device you are using. Thanks. I am using two test devices, one is a simple EZ-USB FX2LP board which is pretty cheap from many places. ![ez_usb_fx2lp_cy7c68013a_usb_development_board_3](https://github.com/user-attachments/assets/5d31c3d2-04ac-4abc-a830-29556e7a42a4) The other is a very old Microchip USB demo board (PIC18F87J50 PIM), not worth buying now. ![518-ma180021](https://github.com/user-attachments/assets/c825ce93-ca17-4094-bd17-49325cde3ceb)
👍 1
mcuee commented 2025-04-02 20:31:25 -05:00 (Migrated from github.com)

There are also github action build failure.

Run make install
[ 12%] Building C object src/linux/CMakeFiles/hidapi_hidraw.dir/hid.c.o
[ 25%] Linking C shared library libhidapi-hidraw.so
[ 25%] Built target hidapi_hidraw
[ 37%] Building C object src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o
/home/runner/work/hidapi/hidapi/hidapisrc/libusb/hid.c: In function ‘get_max_report_size’:
/home/runner/work/hidapi/hidapi/hidapisrc/libusb/hid.c:331:2[9](https://github.com/libusb/hidapi/actions/runs/14115441113/job/39887008870?pr=728#step:5:10): error: comparison of integer expressions of different signedness: ‘int’ and ‘enum report_descr_type’ [-Werror=sign-compare]
  331 |                 if (key_cmd == report_type) { /* Input / Output / Feature */
      |                             ^~
cc1: all warnings being treated as errors
make[2]: *** [src/libusb/CMakeFiles/hidapi_libusb.dir/build.make:79: src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:206: src/libusb/CMakeFiles/hidapi_libusb.dir/all] Error 2
make: *** [Makefile:[13](https://github.com/libusb/hidapi/actions/runs/14115441113/job/39887008870?pr=728#step:5:14)6: all] Error 2
Error: Process completed with exit code 2.
There are also github action build failure. ``` Run make install [ 12%] Building C object src/linux/CMakeFiles/hidapi_hidraw.dir/hid.c.o [ 25%] Linking C shared library libhidapi-hidraw.so [ 25%] Built target hidapi_hidraw [ 37%] Building C object src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o /home/runner/work/hidapi/hidapi/hidapisrc/libusb/hid.c: In function ‘get_max_report_size’: /home/runner/work/hidapi/hidapi/hidapisrc/libusb/hid.c:331:2[9](https://github.com/libusb/hidapi/actions/runs/14115441113/job/39887008870?pr=728#step:5:10): error: comparison of integer expressions of different signedness: ‘int’ and ‘enum report_descr_type’ [-Werror=sign-compare] 331 | if (key_cmd == report_type) { /* Input / Output / Feature */ | ^~ cc1: all warnings being treated as errors make[2]: *** [src/libusb/CMakeFiles/hidapi_libusb.dir/build.make:79: src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:206: src/libusb/CMakeFiles/hidapi_libusb.dir/all] Error 2 make: *** [Makefile:[13](https://github.com/libusb/hidapi/actions/runs/14115441113/job/39887008870?pr=728#step:5:14)6: all] Error 2 Error: Process completed with exit code 2. ```
Youw commented 2025-05-18 13:10:04 -05:00 (Migrated from github.com)

I lost track on this one a bit. Can someone remind where do we stand right now? Except for failing CI - are there active change requests/fixes?

I lost track on this one a bit. Can someone remind where do we stand right now? Except for failing CI - are there active change requests/fixes?
mcuee commented 2025-05-18 18:46:24 -05:00 (Migrated from github.com)

I lost track on this one a bit. Can someone remind where do we stand right now? Except for failing CI - are there active change requests/fixes?

It just does not work based on my testing, tested under Linux and FreeBSD using hidapitester. I also tested under Windows (with a minor hack on the hidapitester Makefile and hidapi libusb backend).

> I lost track on this one a bit. Can someone remind where do we stand right now? Except for failing CI - are there active change requests/fixes? It just does not work based on my testing, tested under Linux and FreeBSD using hidapitester. I also tested under Windows (with a minor hack on the hidapitester Makefile and hidapi libusb backend).
mcuee commented 2025-05-18 18:47:33 -05:00 (Migrated from github.com)

@sudobash1

Just wondering what is the test device you are using. Thanks. Please share the test results as well. I'd like to see if I can use similar test env as yours.

@sudobash1 Just wondering what is the test device you are using. Thanks. Please share the test results as well. I'd like to see if I can use similar test env as yours.
sudobash1 commented 2025-05-21 16:42:15 -05:00 (Migrated from github.com)

Sorry for going dark on this.

Just wondering what is the test device you are using. Thanks. Please share the test results as well. I'd like to see if I can use similar test env as yours.

@mcuee I made these changes to support a Chameleon 20 braille display in USB HID mode. Long story short I needed it to work with an embedded Linux system that is stuck on the 4.x kernel which predates HIDIOCSINPUT. So I switched to the libusb backend and ran into the report size issue. I also tested the libusb changes on a Fedora 39 machine.

I am getting a EZ-USB FX2LP board, so if you point me towards the firmware, I can try out that device. (Much cheaper than the Chameleon 😁)

For me this grew out of a project for my work (the Chameleon with embedded Linux). Things have gotten pretty hectic, but I'm putting a reminder on my calendar to review this again in June.

Sorry for going dark on this. > Just wondering what is the test device you are using. Thanks. Please share the test results as well. I'd like to see if I can use similar test env as yours. @mcuee I made these changes to support a [Chameleon 20 braille display](https://www.aph.org/product/chameleon-20/) in USB HID mode. Long story short I needed it to work with an embedded Linux system that is stuck on the 4.x kernel which predates HIDIOCSINPUT. So I switched to the libusb backend and ran into the report size issue. I also tested the libusb changes on a Fedora 39 machine. I am getting a EZ-USB FX2LP board, so if you point me towards the firmware, I can try out that device. (Much cheaper than the Chameleon :grin:) For me this grew out of a project for my work (the Chameleon with embedded Linux). Things have gotten pretty hectic, but I'm putting a reminder on my calendar to review this again in June.
👍 1
mcuee commented 2025-05-21 17:25:16 -05:00 (Migrated from github.com)

@sudobash1

FW binary and source codes are here.

It is a quick minor modification of Jan Axelson's FX2HID example from here.
http://janaxelson.com/hidpage.htm
http://janaxelson.com/files/fx2hid.zip

There may be a bit of challenge if you want to rebuild the source code as it may require a full version of Keil C51 compiler. I happen to have access to a pretty old version of Keil C51 compiler at work. I am not so sure about the efforts to port the code to use the free sdcc toolchain. It may be possible because of the nice sdcc based libraries.

  1. https://github.com/djmuhlestein/fx2lib
  2. https://github.com/whitequark/libfx2

Jan's HID page has some other FW as well, for example, for Microchip USB PIC18. I was able to use that as a base for my other HIDAPI testing but I have not figured out how to increase the HID report size above 64 bytes with that FW. I have the PIC18F87J50 USB PIM (free tool from Microchip many years ago).

More testing device discussions:

@sudobash1 FW binary and source codes are here. * https://github.com/libusb/hidapi/issues/478#issuecomment-1547963784 It is a quick minor modification of Jan Axelson's FX2HID example from here. http://janaxelson.com/hidpage.htm http://janaxelson.com/files/fx2hid.zip There may be a bit of challenge if you want to rebuild the source code as it may require a full version of Keil C51 compiler. I happen to have access to a pretty old version of Keil C51 compiler at work. I am not so sure about the efforts to port the code to use the free sdcc toolchain. It may be possible because of the nice sdcc based libraries. 1. https://github.com/djmuhlestein/fx2lib 2. https://github.com/whitequark/libfx2 Jan's HID page has some other FW as well, for example, for Microchip USB PIC18. I was able to use that as a base for my other HIDAPI testing but I have not figured out how to increase the HID report size above 64 bytes with that FW. I have the PIC18F87J50 USB PIM (free tool from Microchip many years ago). More testing device discussions: * https://github.com/libusb/hidapi/discussions/743
mcuee commented 2025-06-16 00:58:58 -05:00 (Migrated from github.com)

Update with the main git branch to trigger another CI run.

Update with the main git branch to trigger another CI run.
mcuee commented 2025-06-16 01:13:26 -05:00 (Migrated from github.com)

@aokblast

Would you please run your test device against this PR for hidspi libusb backend under your FreeBSD (as well as other OS you have access to)? Thanks.

@aokblast Would you please run your test device against this PR for hidspi libusb backend under your FreeBSD (as well as other OS you have access to)? Thanks.
mcuee commented 2025-06-16 19:16:53 -05:00 (Migrated from github.com)

@cederom and @dl8dtl

Since you two are the FreeBSD power user I know of, please help to check if you can give this PR a try.

FreeBSD HIDAPI is now based on libusb, so it is affected by the Issue #274.

#274 has an impact on avrdude as well.

@cederom and @dl8dtl Since you two are the FreeBSD power user I know of, please help to check if you can give this PR a try. FreeBSD HIDAPI is now based on libusb, so it is affected by the Issue #274. * #274 #274 has an impact on avrdude as well.
👍 1
cederom commented 2025-06-16 21:06:25 -05:00 (Migrated from github.com)

@mcuee builds okay, could you please provide test steps, its a long thread :-P

@mcuee builds okay, could you please provide test steps, its a long thread :-P
mcuee commented 2025-06-17 00:31:28 -05:00 (Migrated from github.com)

@mcuee builds okay, could you please provide test steps, its a long thread :-P

Great.

Test steps: using the normal libusb backend of HIDAPI and this PR.

  1. Test with your normal generic USB HID device using hidapi's built-in hidtest and hidapitester. This should be okay.
    https://github.com/todbot/hidapitester

  2. Test with USB Full Speed HID device with >64 Bytes HID report size. This may fail.

  3. Test with USB High Speed HID device with >64 Bytes HID report side. This may fail.

I have mentioned my test device in the comments above (EZ-USB FX2LP) but you can use other test device if you can.

> @mcuee builds okay, could you please provide test steps, its a long thread :-P Great. Test steps: using the normal libusb backend of HIDAPI and this PR. 1) Test with your normal generic USB HID device using hidapi's built-in hidtest and hidapitester. This should be okay. https://github.com/todbot/hidapitester 2) Test with USB Full Speed HID device with >64 Bytes HID report size. This may fail. 3) Test with USB High Speed HID device with >64 Bytes HID report side. This may fail. I have mentioned my test device in the comments above (EZ-USB FX2LP) but you can use other test device if you can. * https://github.com/libusb/hidapi/pull/728#issuecomment-2899398658
👍 1
sudobash1 commented 2025-06-17 14:20:06 -05:00 (Migrated from github.com)

@mcuee

FW binary and source codes are here.

Thanks. I finally got my EZ-USB FX2LP dev board from ebay. I've never worked with these before. How do I flash the hex file onto them? This is as far as I got:

stephen@taurus:~$ lsusb | grep FX2
Bus 001 Device 017: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
stephen@taurus:~$ sudo fxload -D /dev/bus/usb/001/017 -I fx2hid_128bytes/fx2hid.hex -v
microcontroller type: fx
single stage:  load on-chip memory
open RAM hexfile image fx2hid_128bytes/fx2hid.hex
stop CPU
write on-chip, addr 0x0600 len  234 (0x00ea)
write on-chip, addr 0x09e5 len   10 (0x000a)
write on-chip, addr 0x0380 len  428 (0x01ac)
write on-chip, addr 0x0080 len  768 (0x0300)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x09ff len    7 (0x0007)
write on-chip, addr 0x07b8 len   92 (0x005c)
write on-chip, addr 0x0851 len   59 (0x003b)
write on-chip, addr 0x05fe len    2 (0x0002)
write on-chip, addr 0x0a07 len    4 (0x0004)
write on-chip, addr 0x09ef len    8 (0x0008)
write on-chip, addr 0x09b0 len   18 (0x0012)
write on-chip, addr 0x09f7 len    8 (0x0008)
write on-chip, addr 0x09c2 len   18 (0x0012)
write on-chip, addr 0x0a0b len    6 (0x0006)
write on-chip, addr 0x091d len   40 (0x0028)
write on-chip, addr 0x096a len   24 (0x0018)
write on-chip, addr 0x06ea len   22 (0x0016)
write on-chip, addr 0x099a len   22 (0x0016)
write on-chip, addr 0x088c len   54 (0x0036)
write on-chip, addr 0x0982 len   24 (0x0018)
write on-chip, addr 0x0814 len   61 (0x003d)
write on-chip, addr 0x0a11 len   36 (0x0024)
write on-chip, addr 0x08f1 len   44 (0x002c)
write on-chip, addr 0x08c2 len   47 (0x002f)
write on-chip, addr 0x0945 len   20 (0x0014)
write on-chip, addr 0x05b8 len   70 (0x0046)
write on-chip, addr 0x0959 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x0700 len  184 (0x00b8)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x052c len   12 (0x000c)
write on-chip, addr 0x09d4 len   17 (0x0011)
write on-chip, addr 0x0538 len  128 (0x0080)
write on-chip, addr 0x0a06 len    1 (0x0001)
... WROTE: 2497 bytes, 36 segments, avg 69
reset CPU

No errors, but nothing seems to happen. No hid device shows up & there is no USB re-enumeration. (Fedora 42, Linux kernel 6.14.11)

@mcuee > FW binary and source codes are here. Thanks. I finally got my EZ-USB FX2LP dev board from ebay. I've never worked with these before. How do I flash the hex file onto them? This is as far as I got: ``` stephen@taurus:~$ lsusb | grep FX2 Bus 001 Device 017: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit stephen@taurus:~$ sudo fxload -D /dev/bus/usb/001/017 -I fx2hid_128bytes/fx2hid.hex -v microcontroller type: fx single stage: load on-chip memory open RAM hexfile image fx2hid_128bytes/fx2hid.hex stop CPU write on-chip, addr 0x0600 len 234 (0x00ea) write on-chip, addr 0x09e5 len 10 (0x000a) write on-chip, addr 0x0380 len 428 (0x01ac) write on-chip, addr 0x0080 len 768 (0x0300) write on-chip, addr 0x0033 len 3 (0x0003) write on-chip, addr 0x09ff len 7 (0x0007) write on-chip, addr 0x07b8 len 92 (0x005c) write on-chip, addr 0x0851 len 59 (0x003b) write on-chip, addr 0x05fe len 2 (0x0002) write on-chip, addr 0x0a07 len 4 (0x0004) write on-chip, addr 0x09ef len 8 (0x0008) write on-chip, addr 0x09b0 len 18 (0x0012) write on-chip, addr 0x09f7 len 8 (0x0008) write on-chip, addr 0x09c2 len 18 (0x0012) write on-chip, addr 0x0a0b len 6 (0x0006) write on-chip, addr 0x091d len 40 (0x0028) write on-chip, addr 0x096a len 24 (0x0018) write on-chip, addr 0x06ea len 22 (0x0016) write on-chip, addr 0x099a len 22 (0x0016) write on-chip, addr 0x088c len 54 (0x0036) write on-chip, addr 0x0982 len 24 (0x0018) write on-chip, addr 0x0814 len 61 (0x003d) write on-chip, addr 0x0a11 len 36 (0x0024) write on-chip, addr 0x08f1 len 44 (0x002c) write on-chip, addr 0x08c2 len 47 (0x002f) write on-chip, addr 0x0945 len 20 (0x0014) write on-chip, addr 0x05b8 len 70 (0x0046) write on-chip, addr 0x0959 len 17 (0x0011) write on-chip, addr 0x0043 len 3 (0x0003) write on-chip, addr 0x0053 len 3 (0x0003) write on-chip, addr 0x0700 len 184 (0x00b8) write on-chip, addr 0x0000 len 3 (0x0003) write on-chip, addr 0x052c len 12 (0x000c) write on-chip, addr 0x09d4 len 17 (0x0011) write on-chip, addr 0x0538 len 128 (0x0080) write on-chip, addr 0x0a06 len 1 (0x0001) ... WROTE: 2497 bytes, 36 segments, avg 69 reset CPU ``` No errors, but nothing seems to happen. No hid device shows up & there is no USB re-enumeration. (Fedora 42, Linux kernel 6.14.11)
👍 1
cederom commented 2025-06-17 14:59:53 -05:00 (Migrated from github.com)

I also ordered EZ-USB FX2LP will arrive next week will report back test results :-)

I also ordered EZ-USB FX2LP will arrive next week will report back test results :-)
👍 1
mcuee commented 2025-06-17 18:25:37 -05:00 (Migrated from github.com)

@mcuee

How do I flash the hex file onto them? This is as far as I got:

stephen@taurus:~$ lsusb | grep FX2
Bus 001 Device 017: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
stephen@taurus:~$ sudo fxload -D /dev/bus/usb/001/017 -I fx2hid_128bytes/fx2hid.hex -v
microcontroller type: fx
...
No errors, but nothing seems to happen. No hid device shows up & there is no USB re-enumeration. (Fedora 42, Linux kernel 6.14.11)

You are almost there. Just need to add -t fx2lp in the command line to specify the type to be EZ-USB FX2LP.

FX --> EZ-USB FX
FX2 --> EZ-USB FX2
FX2LP --> EZ-USB FX2LP
FX3 --> EZ-USB FX3

[mcuee@CachyN100 fx2hid_128bytes]$ yay -S yay

[mcuee@CachyN100 fx2hid_128bytes]$ lsusb | grep FX2
Bus 003 Device 011: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

[mcuee@CachyN100 fx2hid_128bytes]$ fxload
no firmware specified!

Usage: fxload [-v] [-V] [-t type] [-d vid:pid] [-p bus,addr] [-s loader] -i firmware
  -i <path>       -- Firmware to upload
  -s <path>       -- Second stage loader
  -t <type>       -- Target type: an21, fx, fx2, fx2lp, fx3
  -d <vid:pid>    -- Target device, as an USB VID:PID
  -p <bus,addr>   -- Target device, as a libusb bus number and device address path
  -v              -- Increase verbosity
  -q              -- Decrease verbosity (silent mode)
  -V              -- Print program version

[mcuee@CachyN100 fx2hid_128bytes]$ sudo fxload -t fx2lp -i ./fx2hid.hex 
found device 'Cypress EZ-USB FX2LP (68013A/68014A/68015A/68016A)' [04b4:8613] (3,11)
microcontroller type: fx2lp
./fx2hid.hex: type Intel HEX
stop CPU
... WROTE: 2497 bytes, 36 segments, avg 69
reset CPU

[mcuee@CachyN100 fx2hid_128bytes]$ lsusb | grep FX2
Bus 003 Device 014: ID 0925:1234 Lakeview Research EZ-USB FX2 HID USBHIDIO
> @mcuee > >How do I flash the hex file onto them? This is as far as I got: > > ``` > stephen@taurus:~$ lsusb | grep FX2 > Bus 001 Device 017: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit > stephen@taurus:~$ sudo fxload -D /dev/bus/usb/001/017 -I fx2hid_128bytes/fx2hid.hex -v > microcontroller type: fx > ... > No errors, but nothing seems to happen. No hid device shows up & there is no USB re-enumeration. (Fedora 42, Linux kernel 6.14.11) You are almost there. Just need to add `-t fx2lp` in the command line to specify the type to be EZ-USB FX2LP. FX --> EZ-USB FX FX2 --> EZ-USB FX2 FX2LP --> EZ-USB FX2LP FX3 --> EZ-USB FX3 ``` [mcuee@CachyN100 fx2hid_128bytes]$ yay -S yay [mcuee@CachyN100 fx2hid_128bytes]$ lsusb | grep FX2 Bus 003 Device 011: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit [mcuee@CachyN100 fx2hid_128bytes]$ fxload no firmware specified! Usage: fxload [-v] [-V] [-t type] [-d vid:pid] [-p bus,addr] [-s loader] -i firmware -i <path> -- Firmware to upload -s <path> -- Second stage loader -t <type> -- Target type: an21, fx, fx2, fx2lp, fx3 -d <vid:pid> -- Target device, as an USB VID:PID -p <bus,addr> -- Target device, as a libusb bus number and device address path -v -- Increase verbosity -q -- Decrease verbosity (silent mode) -V -- Print program version [mcuee@CachyN100 fx2hid_128bytes]$ sudo fxload -t fx2lp -i ./fx2hid.hex found device 'Cypress EZ-USB FX2LP (68013A/68014A/68015A/68016A)' [04b4:8613] (3,11) microcontroller type: fx2lp ./fx2hid.hex: type Intel HEX stop CPU ... WROTE: 2497 bytes, 36 segments, avg 69 reset CPU [mcuee@CachyN100 fx2hid_128bytes]$ lsusb | grep FX2 Bus 003 Device 014: ID 0925:1234 Lakeview Research EZ-USB FX2 HID USBHIDIO ```
mcuee commented 2025-06-17 18:41:17 -05:00 (Migrated from github.com)

@sudobash1

Fedora 42's fxload (kind of original version of fxload) is a bit different and it does not support FX3. But it does support FX2LP.

mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ fxload
no device specified!
usage: fxload [-vV] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp
... at least one of -I, -L, -m is required

mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ lsusb | grep FX2
Bus 003 Device 009: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ sudo fxload -D /dev/bus/usb/003/009 -t fx2lp -I ./fx2hid.hex -v
microcontroller type: fx2lp
single stage:  load on-chip memory
open RAM hexfile image ./fx2hid.hex
stop CPU
write on-chip, addr 0x0600 len  234 (0x00ea)
write on-chip, addr 0x09e5 len   10 (0x000a)
write on-chip, addr 0x0380 len  428 (0x01ac)
write on-chip, addr 0x0080 len  768 (0x0300)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x09ff len    7 (0x0007)
write on-chip, addr 0x07b8 len   92 (0x005c)
write on-chip, addr 0x0851 len   59 (0x003b)
write on-chip, addr 0x05fe len    2 (0x0002)
write on-chip, addr 0x0a07 len    4 (0x0004)
write on-chip, addr 0x09ef len    8 (0x0008)
write on-chip, addr 0x09b0 len   18 (0x0012)
write on-chip, addr 0x09f7 len    8 (0x0008)
write on-chip, addr 0x09c2 len   18 (0x0012)
write on-chip, addr 0x0a0b len    6 (0x0006)
write on-chip, addr 0x091d len   40 (0x0028)
write on-chip, addr 0x096a len   24 (0x0018)
write on-chip, addr 0x06ea len   22 (0x0016)
write on-chip, addr 0x099a len   22 (0x0016)
write on-chip, addr 0x088c len   54 (0x0036)
write on-chip, addr 0x0982 len   24 (0x0018)
write on-chip, addr 0x0814 len   61 (0x003d)
write on-chip, addr 0x0a11 len   36 (0x0024)
write on-chip, addr 0x08f1 len   44 (0x002c)
write on-chip, addr 0x08c2 len   47 (0x002f)
write on-chip, addr 0x0945 len   20 (0x0014)
write on-chip, addr 0x05b8 len   70 (0x0046)
write on-chip, addr 0x0959 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x0700 len  184 (0x00b8)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x052c len   12 (0x000c)
write on-chip, addr 0x09d4 len   17 (0x0011)
write on-chip, addr 0x0538 len  128 (0x0080)
write on-chip, addr 0x0a06 len    1 (0x0001)
... WROTE: 2497 bytes, 36 segments, avg 69
reset CPU

mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ lsusb | grep FX2
Bus 003 Device 010: ID 0925:1234 Lakeview Research EZ-USB FX2 HID USBHIDIO
@sudobash1 Fedora 42's fxload (kind of original version of fxload) is a bit different and it does not support FX3. But it does support FX2LP. ``` mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ fxload no device specified! usage: fxload [-vV] [-l] [-t type] [-D devpath] [-I firmware_hexfile] [-s loader] [-c config_byte] [-L link] [-m mode] ... [-D devpath] overrides DEVICE= in env ... device types: one of an21, fx, fx2, fx2lp ... at least one of -I, -L, -m is required mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ lsusb | grep FX2 Bus 003 Device 009: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ sudo fxload -D /dev/bus/usb/003/009 -t fx2lp -I ./fx2hid.hex -v microcontroller type: fx2lp single stage: load on-chip memory open RAM hexfile image ./fx2hid.hex stop CPU write on-chip, addr 0x0600 len 234 (0x00ea) write on-chip, addr 0x09e5 len 10 (0x000a) write on-chip, addr 0x0380 len 428 (0x01ac) write on-chip, addr 0x0080 len 768 (0x0300) write on-chip, addr 0x0033 len 3 (0x0003) write on-chip, addr 0x09ff len 7 (0x0007) write on-chip, addr 0x07b8 len 92 (0x005c) write on-chip, addr 0x0851 len 59 (0x003b) write on-chip, addr 0x05fe len 2 (0x0002) write on-chip, addr 0x0a07 len 4 (0x0004) write on-chip, addr 0x09ef len 8 (0x0008) write on-chip, addr 0x09b0 len 18 (0x0012) write on-chip, addr 0x09f7 len 8 (0x0008) write on-chip, addr 0x09c2 len 18 (0x0012) write on-chip, addr 0x0a0b len 6 (0x0006) write on-chip, addr 0x091d len 40 (0x0028) write on-chip, addr 0x096a len 24 (0x0018) write on-chip, addr 0x06ea len 22 (0x0016) write on-chip, addr 0x099a len 22 (0x0016) write on-chip, addr 0x088c len 54 (0x0036) write on-chip, addr 0x0982 len 24 (0x0018) write on-chip, addr 0x0814 len 61 (0x003d) write on-chip, addr 0x0a11 len 36 (0x0024) write on-chip, addr 0x08f1 len 44 (0x002c) write on-chip, addr 0x08c2 len 47 (0x002f) write on-chip, addr 0x0945 len 20 (0x0014) write on-chip, addr 0x05b8 len 70 (0x0046) write on-chip, addr 0x0959 len 17 (0x0011) write on-chip, addr 0x0043 len 3 (0x0003) write on-chip, addr 0x0053 len 3 (0x0003) write on-chip, addr 0x0700 len 184 (0x00b8) write on-chip, addr 0x0000 len 3 (0x0003) write on-chip, addr 0x052c len 12 (0x000c) write on-chip, addr 0x09d4 len 17 (0x0011) write on-chip, addr 0x0538 len 128 (0x0080) write on-chip, addr 0x0a06 len 1 (0x0001) ... WROTE: 2497 bytes, 36 segments, avg 69 reset CPU mcuee@fedoran100:~/build/cypress/fx2hid_128bytes$ lsusb | grep FX2 Bus 003 Device 010: ID 0925:1234 Lakeview Research EZ-USB FX2 HID USBHIDIO ```
mcuee commented 2025-06-17 18:43:44 -05:00 (Migrated from github.com)

Interestingly Arch Linux AUR fxload is actually packing libusb project's fxload example.
https://github.com/libusb/libusb/tree/master/examples

https://aur.archlinux.org/packages/fxload
Git Clone URL: https://aur.archlinux.org/fxload.git (read-only, click to copy)
Package Base: fxload
Description: fxload firmware loader. Used with udev or devfs/hotplug.
Upstream URL: http://libusb.info/

Interestingly Arch Linux AUR fxload is actually packing libusb project's fxload example. https://github.com/libusb/libusb/tree/master/examples https://aur.archlinux.org/packages/fxload Git Clone URL: https://aur.archlinux.org/fxload.git (read-only, click to copy) Package Base: fxload Description: fxload firmware loader. Used with udev or devfs/hotplug. Upstream URL: http://libusb.info/
mcuee commented 2025-06-17 18:58:37 -05:00 (Migrated from github.com)

Interestingly there is a Fedora request to package libusb's fxload example (probably as libusb-fxload) but it is not implemented in the end.
https://bugzilla.redhat.com/show_bug.cgi?id=1907078

Take note libusb's fxload does not support EEPROM. So the suggeston from @jwrdegoede is good in the above discussion. libusb's fxload example cannot replace the original fxload, it is better to have both packages in Fedora.

Initial commit in libusb project
github.com/libusb/libusb@05975333c5

FX3 support:
github.com/libusb/libusb@b74b7f7390

Interestingly there is a Fedora request to package libusb's fxload example (probably as libusb-fxload) but it is not implemented in the end. https://bugzilla.redhat.com/show_bug.cgi?id=1907078 Take note libusb's fxload does not support EEPROM. So the suggeston from @jwrdegoede is good in the above discussion. libusb's fxload example cannot replace the original fxload, it is better to have both packages in Fedora. Initial commit in libusb project https://github.com/libusb/libusb/commit/05975333c53d58a98b1e91f1edd220d794c7dd46 FX3 support: https://github.com/libusb/libusb/commit/b74b7f7390690f631274b46ef2bbe7984d825eec
sudobash1 commented 2025-06-17 19:18:36 -05:00 (Migrated from github.com)

@mcuee Thanks, I have it running now. I am experiencing the same things you are. I added a quick printf to libusb/hid.c to check the dev->max_input_report_size. It reports 129:

stephen@taurus:~/src/hidapitester/hidapitester$ git -C ../hidapi-fork/ diff
diff --git i/libusb/hid.c w/libusb/hid.c
index aee5782..05a3370 100644
--- i/libusb/hid.c
+++ w/libusb/hid.c
@@ -1313,6 +1313,7 @@ static int hidapi_initialize_device(hid_device *dev, const struct libusb_interfa
        int desc_size = hid_get_report_descriptor_libusb(dev->device_handle, dev->interface, dev->report_descriptor_size, report_descriptor, sizeof(report>
        if (desc_size > 0) {
                dev->max_input_report_size = get_max_report_size(report_descriptor, desc_size, REPORT_DESCR_INPUT);
+               printf("computed max input report size (rounded): %zu\n", dev->max_input_report_size);
        } else {
                dev->max_input_report_size = 0;
        }
stephen@taurus:~/src/hidapitester/hidapitester$ sudo ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input | grep "computed"
computed max input report size (rounded): 129

So, this PR is computing what I would have expected for the max input report size from the device descriptor. But I notice with hidraw, it is only reading 128 bytes (not 129). So as a quick kludge test, I removed the + 1 from the report size, and it works:

stephen@taurus:~/src/hidapitester/hidapitester$ git -C ../hidapi-fork/ diff
diff --git i/libusb/hid.c w/libusb/hid.c
index aee5782..7d28b17 100644
--- i/libusb/hid.c
+++ w/libusb/hid.c
@@ -356,7 +356,7 @@ static size_t get_max_report_size(uint8_t * report_descriptor, int desc_size, en
        } else {
                /* report_size is in bits. Determine the total size convert to bytes
                (rounded up), and add one byte for the report number. */
-               return ((max_size + 7) / 8) + 1;
+               return ((max_size + 7) / 8);
        }
 }
 
stephen@taurus:~/src/hidapitester/hidapitester$ sudo ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

It looks like the input report doesn't use a report number, so there are only 128 bytes sent. Right now, I'm guessing that the issue is something to do with the fact that 128 is an even multiple of the packet size, so USB isn't sending any short packet.

I've got a cold right now, so my head has been a bit fuzzy. I will have to revisit this at a later time with a clearer head.

tl;dr

It looks like the code in this PR to parse the report descriptor is working, but libusb isn't reading a 128 byte message when it expected a 129-byte one.

Anybody have more insight into this?

Cheers! 🍻

@mcuee Thanks, I have it running now. I am experiencing the same things you are. I added a quick `printf` to `libusb/hid.c` to check the `dev->max_input_report_size`. It reports 129: ``` stephen@taurus:~/src/hidapitester/hidapitester$ git -C ../hidapi-fork/ diff diff --git i/libusb/hid.c w/libusb/hid.c index aee5782..05a3370 100644 --- i/libusb/hid.c +++ w/libusb/hid.c @@ -1313,6 +1313,7 @@ static int hidapi_initialize_device(hid_device *dev, const struct libusb_interfa int desc_size = hid_get_report_descriptor_libusb(dev->device_handle, dev->interface, dev->report_descriptor_size, report_descriptor, sizeof(report> if (desc_size > 0) { dev->max_input_report_size = get_max_report_size(report_descriptor, desc_size, REPORT_DESCR_INPUT); + printf("computed max input report size (rounded): %zu\n", dev->max_input_report_size); } else { dev->max_input_report_size = 0; } stephen@taurus:~/src/hidapitester/hidapitester$ sudo ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input | grep "computed" computed max input report size (rounded): 129 ``` So, this PR is computing what I would have expected for the max input report size from the device descriptor. But I notice with hidraw, it is only reading 128 bytes (not 129). So as a quick kludge test, I removed the `+ 1` from the report size, and it works: ``` stephen@taurus:~/src/hidapitester/hidapitester$ git -C ../hidapi-fork/ diff diff --git i/libusb/hid.c w/libusb/hid.c index aee5782..7d28b17 100644 --- i/libusb/hid.c +++ w/libusb/hid.c @@ -356,7 +356,7 @@ static size_t get_max_report_size(uint8_t * report_descriptor, int desc_size, en } else { /* report_size is in bits. Determine the total size convert to bytes (rounded up), and add one byte for the report number. */ - return ((max_size + 7) / 8) + 1; + return ((max_size + 7) / 8); } } stephen@taurus:~/src/hidapitester/hidapitester$ sudo ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ``` It looks like the input report doesn't use a report number, so there are only 128 bytes sent. Right now, I'm guessing that the issue is something to do with the fact that 128 is an even multiple of the packet size, so USB isn't sending any short packet. I've got a cold right now, so my head has been a bit fuzzy. I will have to revisit this at a later time with a clearer head. __tl;dr__ It looks like the code in this PR to parse the report descriptor is working, but libusb isn't reading a 128 byte message when it expected a 129-byte one. Anybody have more insight into this? Cheers! 🍻
👍 1
JoergAtGithub commented 2025-06-17 21:00:57 -05:00 (Migrated from github.com)

For interupt transfers, which are send without requests from the device to the computer, the ReportId byte ist only prepend to the report data, if the device uses ReportIDs.
Therefore you need to determine from the report descriptor, if the device uses ReportIDs. If anywhere in the report descriptor REPORT_ID occurs, you need, to increase all transfer sizes by one byte for the ReportID.

For interupt transfers, which are send without requests from the device to the computer, the ReportId byte ist only prepend to the report data, if the device uses ReportIDs. Therefore you need to determine from the report descriptor, if the device uses ReportIDs. If anywhere in the report descriptor REPORT_ID occurs, you need, to increase all transfer sizes by one byte for the ReportID.
👍 1
mcuee commented 2025-06-17 21:38:02 -05:00 (Migrated from github.com)

@sudobash1

I think you are close to find the root cause of the issue.

https://github.com/sudobash1/hidapi/blob/libusb_input_size/libusb/hid.c

	if (max_size == 0) {
		// No matching reports found
		return 0;
	} else {
		/* report_size is in bits. Determine the total size convert to bytes
		(rounded up), and add one byte for the report number. */
		return ((max_size + 7) / 8) + 1;
	}

It is kind of a complicated topic. Please refer to the following discussion.

Good comments in that issue by @JoergAtGithub

0 is a placeholder and not a Report ID. This is because the HID class specification specifies "If a Report ID tag was used in the Report descriptor, all reports include a single byte ID prefix. If the Report ID tag was not used, all values are returned in a single report and a prefix ID is not included in that report." and further about the representation in the ReportDescriptor "Set Report ID to 0 (zero) if Report IDs are not used."

Therefore only values from 1 to 255 can be Report IDs. The value 0 can be used in the ReportDescriptor, to define that the reports do not contain a ReportID.

Windows implements it as specified in the class specification and adds the Report ID prefix byte only for devices that use Report IDs.

I know that we need to keep backward compatibility, but from a clean API I would expect a clear seperation between address and data in two arguments.

You can also refer to my comment.

That's exactly my point. Having report ID at the beginning of the buffer - means not extra buffer "prepending" on HIDAPI side.

There are two aspects of the issue.

1. Buffer handling -- platform specific.

I think the current codes already do that. For example, Windows codes have already done that, at least for Output Report and Feature Report (first byte of the report is the report ID, 0 when there is no report ID). And I believe all platforms are doing that for Feature report, based on my testing results.

I tend to believe the current codes are already fine in this aspect, i.e, we do not have issues in terms of getting thngs done (the device will receive the right data, host will also receive the right data).

2. Read/Write lentgh reporting

I think this is the issue now. It is not consistent.

Two ways of reporting -- now we are mixing the two. a) lengh of the buffer used by underlying OS driver -- Feature Report (including the 0 byte for device without Report ID). Currently I believe there is no behaviour differences for Feature Report across platforms.

b) length of the data bytes appearing on the USB Bus -- Input Report (not including the 0 byte for device without Report ID). For Windows, this could be due to the way we handle Input Report differently from Output Report and Feature report. Currently I believe there is no behaviour differences for Input Report across platforms.

c) mix of the two ways -- Output Report (Windows always including the 0 byte for device without Report ID, other platforms may or may not including). So Windows may report one byte more than the other platforms or may report the same length as the other platforms. I think we should at least fix this one.

3. Potential Solution for Issue 2. a) If we really want to unify all platforms in terms of the read/write length report mechanism, then I tend to htink Option b is the way to go for all three types of reports. But then it may require some jobs across all platforms and for Output and Feature reports..

b) If we just want to unify the behavior across platforms, then we only need to fix Output Report write length reporting to the user. I tend to think we only need to make Windows consistent with others. So only one platform (Windows) and one report type (Output Report) needs to be fixed.

@sudobash1 I think you are close to find the root cause of the issue. https://github.com/sudobash1/hidapi/blob/libusb_input_size/libusb/hid.c ``` if (max_size == 0) { // No matching reports found return 0; } else { /* report_size is in bits. Determine the total size convert to bytes (rounded up), and add one byte for the report number. */ return ((max_size + 7) / 8) + 1; } ``` It is kind of a complicated topic. Please refer to the following discussion. * https://github.com/libusb/hidapi/issues/589 Good comments in that issue by @JoergAtGithub * https://github.com/libusb/hidapi/issues/589#issuecomment-1595134978 > `0` is a placeholder and not a Report ID. This is because the HID class specification specifies _"If a Report ID tag was used in the Report descriptor, all reports include a single byte ID prefix. If the Report ID tag was not used, all values are returned in a single report and a prefix ID is not included in that report."_ and further about the representation in the ReportDescriptor _"Set Report ID to 0 (zero) if Report IDs are not used."_ > > Therefore only values from 1 to 255 can be Report IDs. The value 0 can be used in the ReportDescriptor, to define that the reports do not contain a ReportID. > > Windows implements it as specified in the class specification and adds the Report ID prefix byte only for devices that use Report IDs. > > I know that we need to keep backward compatibility, but from a clean API I would expect a clear seperation between address and data in two arguments. You can also refer to my comment. * https://github.com/libusb/hidapi/issues/589#issuecomment-1595670077 > > That's exactly my point. Having report ID at the beginning of the buffer - means not extra buffer "prepending" on HIDAPI side. > > There are two aspects of the issue. > > **1. Buffer handling -- platform specific.** > > I think the current codes already do that. For example, Windows codes have already done that, at least for Output Report and Feature Report (first byte of the report is the report ID, 0 when there is no report ID). And I believe all platforms are doing that for Feature report, based on my testing results. > > I tend to believe the current codes are already fine in this aspect, i.e, we do not have issues in terms of getting thngs done (the device will receive the right data, host will also receive the right data). > > **2. Read/Write lentgh reporting** > > I think this is the issue now. It is not consistent. > > Two ways of reporting -- now we are mixing the two. a) lengh of the buffer used by underlying OS driver -- Feature Report (including the 0 byte for device without Report ID). Currently I believe there is no behaviour differences for Feature Report across platforms. > > b) length of the data bytes appearing on the USB Bus -- Input Report (not including the 0 byte for device without Report ID). For Windows, this could be due to the way we handle Input Report differently from Output Report and Feature report. Currently I believe there is no behaviour differences for Input Report across platforms. > > c) mix of the two ways -- Output Report (Windows always including the 0 byte for device without Report ID, other platforms may or may not including). So Windows may report one byte more than the other platforms or may report the same length as the other platforms. I think we should at least fix this one. > > **3. Potential Solution for Issue 2.** a) If we really want to unify all platforms in terms of the read/write length report mechanism, then I tend to htink Option b is the way to go for all three types of reports. But then it may require some jobs across all platforms and for Output and Feature reports.. > > b) If we just want to unify the behavior across platforms, then we only need to fix Output Report write length reporting to the user. I tend to think we only need to make Windows consistent with others. So only one platform (Windows) and one report type (Output Report) needs to be fixed.
sudobash1 commented 2025-06-18 19:50:54 -05:00 (Migrated from github.com)

Thank you @JoergAtGithub and @mcuee. That is clearly the issue. I reviewed the HID spec again and indeed it says:

If a Report ID tag is used anywhere in Report descriptor, all data reports for the device are preceded by a single byte ID field

The Windows behavior when there is no ReportID was tripping me up.

I've pushed a simple commit to address this, and the FX2LP 128-byte report test works fine for me now.

The tests also needed to be fixed for the cases when there is no ReportID (ReportId = 0x00 in the pp_data file).

Am I forgetting anything, or does that finish everything outstanding on this PR (provided CI completes and @mcuee's & @cederom's tests pass)?

Thank you @JoergAtGithub and @mcuee. That is clearly the issue. I reviewed the [HID spec again](https://www.usb.org/sites/default/files/hid1_11.pdf) and indeed it says: > If a Report ID tag is used anywhere in Report descriptor, all data reports for the device are preceded by a single byte ID field The Windows behavior when there is no ReportID was tripping me up. I've pushed a simple commit to address this, and the FX2LP 128-byte report test works fine for me now. The tests also needed to be fixed for the cases when there is no ReportID (`ReportId = 0x00` in the `pp_data` file). Am I forgetting anything, or does that finish everything outstanding on this PR (provided CI completes and @mcuee's & @cederom's tests pass)?
👍 1 ❤️ 1
cederom commented 2025-06-18 19:55:55 -05:00 (Migrated from github.com)

@sudobash1 great news! I will be able to provide soonest feedback around Monday sorry if you are ready before and want to go ahead then go ahead :-) I am waiting for the board and will have to see how to set things up but then I will be able to help you in other cases :-)

Is there any sort of bad-usb device out there that could provide us various test cases from hardware point of view (i.e. simulate bad descriptors, strange transfers, etc)?

@sudobash1 great news! I will be able to provide soonest feedback around Monday sorry if you are ready before and want to go ahead then go ahead :-) I am waiting for the board and will have to see how to set things up but then I will be able to help you in other cases :-) Is there any sort of bad-usb device out there that could provide us various test cases from hardware point of view (i.e. simulate bad descriptors, strange transfers, etc)?
👍 1
mcuee commented 2025-06-19 01:55:31 -05:00 (Migrated from github.com)

@sudobash1

Other than testing, @Youw will need to review the codes and then approve this PR.

But now the first thing is to fix the CI build -- two builds failed because of the same issue.

[ 37%] Building C object src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o
/__w/hidapi/hidapi/hidapisrc/libusb/hid.c: In function ‘get_max_report_size’:
/__w/hidapi/hidapi/hidapisrc/libusb/hid.c:333:29: error: comparison of integer expressions of different signedness: ‘int’ and ‘enum report_descr_type’ [-Werror=sign-compare]
  333 |                 if (key_cmd == report_type) { /* Input / Output / Feature */
      |                             ^~
cc1: all warnings being treated as errors
make[2]: *** [src/libusb/CMakeFiles/hidapi_libusb.dir/build.make:79: src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:206: src/libusb/CMakeFiles/hidapi_libusb.dir/all] Error 2
make: *** [Makefile:[13](https://github.com/libusb/hidapi/actions/runs/15746712859/job/44397056740?pr=728#step:7:14)6: all] Error 2
@sudobash1 Other than testing, @Youw will need to review the codes and then approve this PR. But now the first thing is to fix the CI build -- two builds failed because of the same issue. ``` [ 37%] Building C object src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o /__w/hidapi/hidapi/hidapisrc/libusb/hid.c: In function ‘get_max_report_size’: /__w/hidapi/hidapi/hidapisrc/libusb/hid.c:333:29: error: comparison of integer expressions of different signedness: ‘int’ and ‘enum report_descr_type’ [-Werror=sign-compare] 333 | if (key_cmd == report_type) { /* Input / Output / Feature */ | ^~ cc1: all warnings being treated as errors make[2]: *** [src/libusb/CMakeFiles/hidapi_libusb.dir/build.make:79: src/libusb/CMakeFiles/hidapi_libusb.dir/hid.c.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:206: src/libusb/CMakeFiles/hidapi_libusb.dir/all] Error 2 make: *** [Makefile:[13](https://github.com/libusb/hidapi/actions/runs/15746712859/job/44397056740?pr=728#step:7:14)6: all] Error 2 ```
sudobash1 commented 2025-06-19 15:24:51 -05:00 (Migrated from github.com)

But now the first thing is to fix the CI build -- two builds failed because of the same issue.

Oops. I thought I had fixed that. I guess not. I have pushed e2391b6 to address compiler warnings. It compiles cleanly with -Wall -Wextra on gcc-15 and clang-20 on my Fedora box now. Hopefully all the CI compile now.

> But now the first thing is to fix the CI build -- two builds failed because of the same issue. Oops. I thought I had fixed that. I guess not. I have pushed [e2391b6](https://github.com/libusb/hidapi/pull/728/commits/e2391b61f9f5156f2b15f4de272083a733ab770f) to address compiler warnings. It compiles cleanly with `-Wall -Wextra` on gcc-15 and clang-20 on my Fedora box now. Hopefully all the CI compile now.
mcuee commented 2025-06-19 21:08:08 -05:00 (Migrated from github.com)

Oops. I thought I had fixed that. I guess not. I have pushed e2391b6 to address compiler warnings. It compiles cleanly with -Wall -Wextra on gcc-15 and clang-20 on my Fedora box now. Hopefully all the CI compile now.

Yes, CI builds are okay now.

> Oops. I thought I had fixed that. I guess not. I have pushed [e2391b6](https://github.com/libusb/hidapi/pull/728/commits/e2391b61f9f5156f2b15f4de272083a733ab770f) to address compiler warnings. It compiles cleanly with `-Wall -Wextra` on gcc-15 and clang-20 on my Fedora box now. Hopefully all the CI compile now. Yes, CI builds are okay now.
sudobash1 commented 2025-06-20 01:04:21 -05:00 (Migrated from github.com)

Ah, it looks like there a few comments from @Youw that I need to address too. Most significant is probably updating builds.yml (to make sure the tests are enabled).

I'll look through this on Friday.

Ah, it looks like there a few comments from @Youw that I need to address too. Most significant is probably updating builds.yml (to make sure the tests are enabled). I'll look through this on Friday.
❤️ 1
JoergAtGithub commented 2025-06-20 01:30:04 -05:00 (Migrated from github.com)

It would be good if it could clarify in the comments what exactly the “report size” returned by get_max_report_size comprises.

  • Here it is only about the InputReports that are sent unrequested by the HID device via interupt transfers (hid_read / hid_read_timeout).
  • However, InputReports can also be actively retrieved with hid_get_input_report via ControlTransfers, where the ReportId byte is always included, even if the device does not use ReportIDs (in this case the ReportID-byte contains the value 0).
  • And get_max_report_size also supports feature and output reports, where it's different too.

In other code of mine, I introduced the unofficial term payload-size for the report size without the ReportID-byte. There I add 1 depending on the context where it is used. There I've also a boolean that indicates, if the device uses ReportIDs.

It would be good if it could clarify in the comments what exactly the “report size” returned by get_max_report_size comprises. - Here it is only about the InputReports that are sent unrequested by the HID device via interupt transfers (hid_read / hid_read_timeout). - However, InputReports can also be actively retrieved with hid_get_input_report via ControlTransfers, where the ReportId byte is always included, even if the device does not use ReportIDs (in this case the ReportID-byte contains the value 0). - And get_max_report_size also supports feature and output reports, where it's different too. In other code of mine, I introduced the unofficial term payload-size for the report size without the ReportID-byte. There I add 1 depending on the context where it is used. There I've also a boolean that indicates, if the device uses ReportIDs.
👍 1
mcuee commented 2025-06-22 19:06:08 -05:00 (Migrated from github.com)

@sudobash1

First test under Windows -- it seems the reported write/read length is not consistent with native API, one byte higher.

Native Windows HID backend-- wrote 129 bytes, read 128 bytes
libusb backend -- wrote 130 bytes, read 129 bytes

But this is getting close. I will test under Linux and FreeBSD later.

 UCRT64 /c/work/libusb/hidapitester
$ ./hidapitester_git_winapi.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

$ ./hidapitester_pr728_libusb_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 130 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 129 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

$ ./hidapitester_pr728_winapi_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37
,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,10
3,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

Dirty fix to be able to build under Windows.

PS C:\work\libusb\hidapi_pr728_new> git diff
diff --git a/libusb/hid.c b/libusb/hid.c
index 0f06389..c830479 100644
--- a/libusb/hid.c
+++ b/libusb/hid.c
@@ -34,8 +34,8 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <sys/utsname.h>
+///#include <sys/ioctl.h>
+//#include <sys/utsname.h>
 #include <fcntl.h>
 #include <wchar.h>

hidapitester Makefile hack and binaries (against hidapi git and this PR, Windows native backend and libusb backend).

hidapitester_win.zip

@sudobash1 First test under Windows -- it seems the reported write/read length is not consistent with native API, one byte higher. Native Windows HID backend-- wrote 129 bytes, read 128 bytes libusb backend -- wrote 130 bytes, read 129 bytes But this is getting close. I will test under Linux and FreeBSD later. ``` UCRT64 /c/work/libusb/hidapitester $ ./hidapitester_git_winapi.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device $ ./hidapitester_pr728_libusb_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 130 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 129 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device $ ./hidapitester_pr728_winapi_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37 ,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,10 3,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ``` Dirty fix to be able to build under Windows. ``` PS C:\work\libusb\hidapi_pr728_new> git diff diff --git a/libusb/hid.c b/libusb/hid.c index 0f06389..c830479 100644 --- a/libusb/hid.c +++ b/libusb/hid.c @@ -34,8 +34,8 @@ #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> -#include <sys/ioctl.h> -#include <sys/utsname.h> +///#include <sys/ioctl.h> +//#include <sys/utsname.h> #include <fcntl.h> #include <wchar.h> ``` hidapitester Makefile hack and binaries (against hidapi git and this PR, Windows native backend and libusb backend). [hidapitester_win.zip](https://github.com/user-attachments/files/20855364/hidapitester_win.zip)
acolombier commented 2025-10-01 17:50:30 -05:00 (Migrated from github.com)

Some findings when testing this patch (on Android) - It looks like report of MAX_SIZE bytes works great now, however, it seems like smaller reports are either slow to be received or sometime even gets discarded

Some findings when testing this patch (on Android) - It looks like report of `MAX_SIZE` bytes works great now, however, it seems like smaller reports are either slow to be received or sometime even gets discarded
cederom commented 2025-10-01 18:33:27 -05:00 (Migrated from github.com)

Sorry for the delay, extremely overloaded, I have the CY7C680 board, working on FreeBSD.

# uname -a
FreeBSD hexagon 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64

# usbconfig
(..)
ugen1.12: <CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Cypress Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

# usbconfig -d 1.12 dump_all_desc
ugen1.12: <CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Cypress Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x00ff  <Vendor specific>
  bDeviceSubClass = 0x00ff
  bDeviceProtocol = 0x00ff
  bMaxPacketSize0 = 0x0040
  idVendor = 0x04b4
  idProduct = 0x8613
  bcdDevice = 0xa001
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0000  <no string>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

 Configuration index 0

    bLength = 0x0009
    bDescriptorType = 0x0002
    wTotalLength = 0x00ab
    bNumInterfaces = 0x0001
    bConfigurationValue = 0x0001
    iConfiguration = 0x0000  <no string>
    bmAttributes = 0x0080
    bMaxPower = 0x0032

    Interface 0
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0000
      bNumEndpoints = 0x0000
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x00ff
      bInterfaceProtocol = 0x00ff
      iInterface = 0x0000  <no string>


    Interface 0 Alt 1
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0001
      bNumEndpoints = 0x0006
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x00ff
      bInterfaceProtocol = 0x00ff
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0001  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 2
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 3
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0004  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 4
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0086  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 5
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0088  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000


    Interface 0 Alt 2
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0002
      bNumEndpoints = 0x0006
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x00ff
      bInterfaceProtocol = 0x00ff
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0001  <OUT>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 2
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0200
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 3
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0004  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 4
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0086  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0200
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 5
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0088  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000


    Interface 0 Alt 3
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0003
      bNumEndpoints = 0x0006
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x00ff
      bInterfaceProtocol = 0x00ff
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0001  <OUT>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 2
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0001  <ISOCHRONOUS>
        wMaxPacketSize = 0x0200
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 3
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0004  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 4
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0086  <IN>
        bmAttributes = 0x0001  <ISOCHRONOUS>
        wMaxPacketSize = 0x0200
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 5
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0088  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

% ./hidapitester --version
hidapitester version: v0.5
hidapi version: 0.16.0

% ./hidapitester --list
0B05/19AF: AsusTek Computer Inc. - AURA LED Controller
534D/2109: MACROSILICON - USB3. 0 capture
0B0E/24CA:  - Jabra Link 380
09DA/6406: A4tech - A4tech KB
09DA/6406: A4tech - A4tech KB
046D/C099: Logitech - G502 X
046D/C099: Logitech - G502 X
044F/B106: Thrustmaster - T.Flight Stick X

Had to power on board with button pressed to be able to flash firmware:

# fxload -t fx2 -I fx2hid_128bytes/fx2hid.hex -D vid=04b4,pid=8613 -v
microcontroller type: fx2
single stage:  load on-chip memory
open RAM hexfile image fx2hid_128bytes/fx2hid.hex
stop CPU
write on-chip, addr 0x0600 len  234 (0x00ea)
write on-chip, addr 0x09e5 len   10 (0x000a)
write on-chip, addr 0x0380 len  428 (0x01ac)
write on-chip, addr 0x0080 len  768 (0x0300)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x09ff len    7 (0x0007)
write on-chip, addr 0x07b8 len   92 (0x005c)
write on-chip, addr 0x0851 len   59 (0x003b)
write on-chip, addr 0x05fe len    2 (0x0002)
write on-chip, addr 0x0a07 len    4 (0x0004)
write on-chip, addr 0x09ef len    8 (0x0008)
write on-chip, addr 0x09b0 len   18 (0x0012)
write on-chip, addr 0x09f7 len    8 (0x0008)
write on-chip, addr 0x09c2 len   18 (0x0012)
write on-chip, addr 0x0a0b len    6 (0x0006)
write on-chip, addr 0x091d len   40 (0x0028)
write on-chip, addr 0x096a len   24 (0x0018)
write on-chip, addr 0x06ea len   22 (0x0016)
write on-chip, addr 0x099a len   22 (0x0016)
write on-chip, addr 0x088c len   54 (0x0036)
write on-chip, addr 0x0982 len   24 (0x0018)
write on-chip, addr 0x0814 len   61 (0x003d)
write on-chip, addr 0x0a11 len   36 (0x0024)
write on-chip, addr 0x08f1 len   44 (0x002c)
write on-chip, addr 0x08c2 len   47 (0x002f)
write on-chip, addr 0x0945 len   20 (0x0014)
write on-chip, addr 0x05b8 len   70 (0x0046)
write on-chip, addr 0x0959 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x0700 len  184 (0x00b8)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x052c len   12 (0x000c)
write on-chip, addr 0x09d4 len   17 (0x0011)
write on-chip, addr 0x0538 len  128 (0x0080)
write on-chip, addr 0x0a06 len    1 (0x0001)
... WROTE: 2497 bytes, 36 segments, avg 69
reset CPU

Now it shows as:

ugen1.12: <CYPRESS EZ-USB FX2 HID USBHIDIO> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA)

% usbconfig -d 1.12 dump_all_desc
ugen1.12: <CYPRESS EZ-USB FX2 HID USBHIDIO> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0925
  idProduct = 0x1234
  bcdDevice = 0x0000
  iManufacturer = 0x0001  <CYPRESS>
  iProduct = 0x0002  <EZ-USB FX2 HID USBHIDIO>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

 Configuration index 0

    bLength = 0x0009
    bDescriptorType = 0x0002
    wTotalLength = 0x0029
    bNumInterfaces = 0x0001
    bConfigurationValue = 0x0001
    iConfiguration = 0x0003  <retrieving string failed>
    bmAttributes = 0x0080
    bMaxPower = 0x0028

    Interface 0
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0000
      bNumEndpoints = 0x0002
      bInterfaceClass = 0x0003  <HID device>
      bInterfaceSubClass = 0x0000
      bInterfaceProtocol = 0x0000
      iInterface = 0x0000  <no string>

      Additional Descriptor

      bLength = 0x09
      bDescriptorType = 0x21
      bDescriptorSubType = 0x10
       RAW dump:
       0x00 | 0x09, 0x21, 0x10, 0x01, 0x00, 0x01, 0x22, 0x34,
       0x08 | 0x00

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0005
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0001  <OUT>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0005
        bRefresh = 0x0000
        bSynchAddress = 0x0000


% ./hidapitester --list
0B05/19AF: AsusTek Computer Inc. - AURA LED Controller
534D/2109: MACROSILICON - USB3. 0 capture
0B0E/24CA:  - Jabra Link 380
09DA/6406: A4tech - A4tech KB
09DA/6406: A4tech - A4tech KB
044F/B106: Thrustmaster - T.Flight Stick X
046D/C099: Logitech - G502 X
046D/C099: Logitech - G502 X
0925/1234: CYPRESS - EZ-USB FX2 HID USBHIDIO


% ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 68 89 37 FE 79 58 09 E7 88 CE 3F 33 9D CF B7 7D 95 C7 8F AD 2E 84 97 EF FF 71 FC 3F F5 D7 70 6E
 9E 93 5E FE F8 DF BA 74 DE B7 AB 6F 9D 3F AF BB 5B FE BF CF BE FB EE 03 B7 EF 8A 0C B3 BB E7 6A
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device


% ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

% ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device
Sorry for the delay, extremely overloaded, I have the CY7C680 board, working on FreeBSD. ``` # uname -a FreeBSD hexagon 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64 # usbconfig (..) ugen1.12: <CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Cypress Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) # usbconfig -d 1.12 dump_all_desc ugen1.12: <CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Cypress Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff <Vendor specific> bDeviceSubClass = 0x00ff bDeviceProtocol = 0x00ff bMaxPacketSize0 = 0x0040 idVendor = 0x04b4 idProduct = 0x8613 bcdDevice = 0xa001 iManufacturer = 0x0000 <no string> iProduct = 0x0000 <no string> iSerialNumber = 0x0000 <no string> bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x00ab bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes = 0x0080 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0000 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 <no string> Interface 0 Alt 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0001 bNumEndpoints = 0x0006 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 <no string> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0086 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0088 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 0 Alt 2 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0002 bNumEndpoints = 0x0006 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 <no string> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 <OUT> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0200 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0086 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0200 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0088 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 0 Alt 3 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0003 bNumEndpoints = 0x0006 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 <no string> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 <OUT> bmAttributes = 0x0001 <ISOCHRONOUS> wMaxPacketSize = 0x0200 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0086 <IN> bmAttributes = 0x0001 <ISOCHRONOUS> wMaxPacketSize = 0x0200 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0088 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 ``` ``` % ./hidapitester --version hidapitester version: v0.5 hidapi version: 0.16.0 % ./hidapitester --list 0B05/19AF: AsusTek Computer Inc. - AURA LED Controller 534D/2109: MACROSILICON - USB3. 0 capture 0B0E/24CA: - Jabra Link 380 09DA/6406: A4tech - A4tech KB 09DA/6406: A4tech - A4tech KB 046D/C099: Logitech - G502 X 046D/C099: Logitech - G502 X 044F/B106: Thrustmaster - T.Flight Stick X ``` Had to power on board with button pressed to be able to flash firmware: ``` # fxload -t fx2 -I fx2hid_128bytes/fx2hid.hex -D vid=04b4,pid=8613 -v microcontroller type: fx2 single stage: load on-chip memory open RAM hexfile image fx2hid_128bytes/fx2hid.hex stop CPU write on-chip, addr 0x0600 len 234 (0x00ea) write on-chip, addr 0x09e5 len 10 (0x000a) write on-chip, addr 0x0380 len 428 (0x01ac) write on-chip, addr 0x0080 len 768 (0x0300) write on-chip, addr 0x0033 len 3 (0x0003) write on-chip, addr 0x09ff len 7 (0x0007) write on-chip, addr 0x07b8 len 92 (0x005c) write on-chip, addr 0x0851 len 59 (0x003b) write on-chip, addr 0x05fe len 2 (0x0002) write on-chip, addr 0x0a07 len 4 (0x0004) write on-chip, addr 0x09ef len 8 (0x0008) write on-chip, addr 0x09b0 len 18 (0x0012) write on-chip, addr 0x09f7 len 8 (0x0008) write on-chip, addr 0x09c2 len 18 (0x0012) write on-chip, addr 0x0a0b len 6 (0x0006) write on-chip, addr 0x091d len 40 (0x0028) write on-chip, addr 0x096a len 24 (0x0018) write on-chip, addr 0x06ea len 22 (0x0016) write on-chip, addr 0x099a len 22 (0x0016) write on-chip, addr 0x088c len 54 (0x0036) write on-chip, addr 0x0982 len 24 (0x0018) write on-chip, addr 0x0814 len 61 (0x003d) write on-chip, addr 0x0a11 len 36 (0x0024) write on-chip, addr 0x08f1 len 44 (0x002c) write on-chip, addr 0x08c2 len 47 (0x002f) write on-chip, addr 0x0945 len 20 (0x0014) write on-chip, addr 0x05b8 len 70 (0x0046) write on-chip, addr 0x0959 len 17 (0x0011) write on-chip, addr 0x0043 len 3 (0x0003) write on-chip, addr 0x0053 len 3 (0x0003) write on-chip, addr 0x0700 len 184 (0x00b8) write on-chip, addr 0x0000 len 3 (0x0003) write on-chip, addr 0x052c len 12 (0x000c) write on-chip, addr 0x09d4 len 17 (0x0011) write on-chip, addr 0x0538 len 128 (0x0080) write on-chip, addr 0x0a06 len 1 (0x0001) ... WROTE: 2497 bytes, 36 segments, avg 69 reset CPU ``` Now it shows as: ``` ugen1.12: <CYPRESS EZ-USB FX2 HID USBHIDIO> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA) % usbconfig -d 1.12 dump_all_desc ugen1.12: <CYPRESS EZ-USB FX2 HID USBHIDIO> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0925 idProduct = 0x1234 bcdDevice = 0x0000 iManufacturer = 0x0001 <CYPRESS> iProduct = 0x0002 <EZ-USB FX2 HID USBHIDIO> iSerialNumber = 0x0000 <no string> bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0029 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0003 <retrieving string failed> bmAttributes = 0x0080 bMaxPower = 0x0028 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0003 <HID device> bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0000 <no string> Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x10 RAW dump: 0x00 | 0x09, 0x21, 0x10, 0x01, 0x00, 0x01, 0x22, 0x34, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x0000 bSynchAddress = 0x0000 % ./hidapitester --list 0B05/19AF: AsusTek Computer Inc. - AURA LED Controller 534D/2109: MACROSILICON - USB3. 0 capture 0B0E/24CA: - Jabra Link 380 09DA/6406: A4tech - A4tech KB 09DA/6406: A4tech - A4tech KB 044F/B106: Thrustmaster - T.Flight Stick X 046D/C099: Logitech - G502 X 046D/C099: Logitech - G502 X 0925/1234: CYPRESS - EZ-USB FX2 HID USBHIDIO % ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 68 89 37 FE 79 58 09 E7 88 CE 3F 33 9D CF B7 7D 95 C7 8F AD 2E 84 97 EF FF 71 FC 3F F5 D7 70 6E 9E 93 5E FE F8 DF BA 74 DE B7 AB 6F 9D 3F AF BB 5B FE BF CF BE FB EE 03 B7 EF 8A 0C B3 BB E7 6A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device % ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device % ./hidapitester --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37 Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device ```
👍 1
acolombier commented 2025-10-31 05:47:25 -05:00 (Migrated from github.com)

I realised I forgot to update my previously flawed comment - the issue was obviously on my end.
Tested this patch on Android and work like a charm! (ref)

I realised I forgot to update my previously flawed comment - the issue was obviously on my end. Tested this patch on Android and work like a charm! ([ref](https://github.com/acolombier/vcpkg/blob/507b17cd873ec0954d34a4641524fed44ddca296/ports/hidapi/portfile.cmake#L8))
👍 1 🎉 1 😆 1
mcuee commented 2025-12-29 20:03:37 -06:00 (Migrated from github.com)

@sudobash1

Just wondering if you have any updates on this one. I think it is pretty close now.

@sudobash1 Just wondering if you have any updates on this one. I think it is pretty close now.
👍 1
mcuee commented 2026-03-19 20:46:06 -05:00 (Migrated from github.com)

Just update the branch to trigger a new build.

It will be good to move this PR forward. May need more testing and reviews.

Just update the branch to trigger a new build. It will be good to move this PR forward. May need more testing and reviews.
👍 1
mcuee commented 2026-04-19 02:57:27 -05:00 (Migrated from github.com)

@Youw

Just wondering if it is worth asking Github Copilot to review this PR. It seems to be pretty close to be okay.

@Youw Just wondering if it is worth asking Github Copilot to review this PR. It seems to be pretty close to be okay.
👍 1
Youw (Migrated from github.com) reviewed 2026-04-19 14:58:52 -05:00
Youw (Migrated from github.com) left a comment

Coming back to this after dropping it for a while — did a spec/kernel cross-check pass and a code re-read. Leaving hardware testing to those with the devices.

Algorithm validation

get_max_report_size matches HID 1.11 (§6.2.2.7, §8 for Report ID semantics) and is structurally identical to Linux's report-descriptor parsing in drivers/hid/hid-core.c:

  • hid_add_field(): report->size += parser->global.report_size * parser->global.report_count;
  • hid_register_report(): if (id != 0) report_enum->numbered = 1;
  • On receive, one byte is consumed as the ID prefix iff numbered — which is exactly the + report_id_used semantic here.

The FX2 128-byte fix is the subtle one: the hang wasn't the size math, it was the unconditional +1 making the buffer a non-multiple of wMaxPacketSize and suppressing the libusb short-packet terminator. Good catch on making it conditional on the Report ID tag actually being used.

Reusing windows/test/data/*.pp_data for a cross-backend parity test is a nice consistency proof.

Suggestions before merge

  1. Scope of "Fixes #274" — this resolves the long-report truncation aspect, but #274 also asks for Full-Speed misconfiguration detection / reporting to the app. Consider softening to "Partially fixes" or adding a note.
  2. Platform length asymmetry that @mcuee observed on Windows (libusb wrote 130 / read 129 vs native HID wrote 129 / read 128) — worth a sentence in the PR body pointing to #731 so users don't re-file it as a regression.
  3. Inline nits on specific lines below.

Algorithm + spec alignment LGTM on the core change.

Extended version:

Comparison with the spec and other implementations
HID 1.11 spec (§6.2.2.7 & §5.6 / §8): "If a Report ID tag is used anywhere in Report descriptor, all data reports for the device are preceded by a single byte ID field." Report ID = 0 is a placeholder meaning "no report IDs". Reports are sized as Σ(report_count × report_size) bits, rounded up to bytes. The PR's algorithm and the conditional +report_id_used byte match the spec exactly.

Windows (HIDP_CAPS): InputReportByteLength/OutputReportByteLength/FeatureReportByteLength — these always include the Report-ID byte (value 0 when unused). That's the source of the read/write-length platform asymmetry and is exactly what follow-up issue #731 is about. The PR's test case subtracts 1 byte from these values when ReportID == 0x00 to reconcile with the libusb convention (see parse_max_input_report_size in max_input_report_size_test.c).

Linux kernel (drivers/hid/hid-core.c): Uses the same algorithm. hid_add_field() accumulates report->size += parser->global.report_size * parser->global.report_count. In hid_register_report(), if (id != 0) report_enum->numbered = 1;. In hid_report_raw_event, when numbered is true the first data byte is consumed as the ID (cdata++; csize--;). Size is bounded by max_buffer_size - 1 bits when numbered. This is structurally identical to what the PR does — so the PR's approach is directly validated by the reference kernel implementation.

hidapi/linux (hidraw backend): Avoids parsing entirely — delegates to the kernel: read(dev->device_handle, data, length) with user-supplied length, because the kernel has already sized the per-report buffer. That's why hidraw "just works" for the 128-byte FX2 firmware and why the libusb backend is the outlier.

Strengths
Correct algorithm. Matches HID 1.11 and Linux kernel's parsing exactly, including the subtle conditional Report-ID byte.
Good test coverage via reuse of 25 real-world Windows pp_data fixtures — this is a nice cross-backend consistency proof.
Safe fallback to input_ep_max_packet_size when the descriptor is corrupt/unparseable — no regression risk for devices already working.
Fixes the classic "exact multiple of max packet size hangs" libusb gotcha — the conditional +1 was the critical insight; without it devices with payloads that happen to be multiples of 64 would hang forever waiting for a short packet.
Remaining concerns worth flagging on review
Re-read of report descriptor. hidapi_initialize_device now calls hid_get_report_descriptor_libusb during init (new control transfer on every open). This is a second descriptor fetch in addition to any caller-driven hid_get_report_descriptor(). Consider caching.
HID_API_MAX_REPORT_DESCRIPTOR_SIZE buffer on stack (4096 bytes typically). libusb/hid.c:1314 in the diff allocates this on the stack — acceptable, but worth noting for embedded targets.
cur_size reset timing. In the parser, cur_size is reset on each Report ID encounter. For descriptors that interleave INPUT/OUTPUT items between Report ID changes this is correct; just note that the max_size comparison happens only at Report-ID boundaries and at the end — which matches the spec semantics where each Report ID opens a fresh report namespace.
Platform-length asymmetry (mcuee's Windows observation) is intentionally out of scope — tracked in #731. Worth linking from the PR description.
PR description still says "Fixes #274" but #274 has broader asks (detection of USB Full-Speed misconfiguration, speed reporting to app). This PR fixes the "long reports get truncated" aspect; the speed/error-reporting aspect remains open.
Typo in test comment (.dpt_desc → .rpt_desc) in libusb/test/CMakeLists.txt.
Bottom line
The PR is technically sound, aligned with HID 1.11 and the Linux kernel reference, and has been hardware-validated on Linux, FreeBSD and Android. The earlier "doesn't work" reports were a spec-compliance bug in the Report-ID handling that sudobash1 fixed. Primary blockers now are administrative: final Youw approval + merge, plus perhaps addressing the minor concerns above. The broader cross-platform length-consistency question is correctly deferred to #731.

Drafted with Claude Code.

Coming back to this after dropping it for a while — did a spec/kernel cross-check pass and a code re-read. Leaving hardware testing to those with the devices. ## Algorithm validation `get_max_report_size` matches HID 1.11 (§6.2.2.7, §8 for Report ID semantics) and is structurally identical to Linux's report-descriptor parsing in `drivers/hid/hid-core.c`: - `hid_add_field()`: `report->size += parser->global.report_size * parser->global.report_count;` - `hid_register_report()`: `if (id != 0) report_enum->numbered = 1;` - On receive, one byte is consumed as the ID prefix iff `numbered` — which is exactly the `+ report_id_used` semantic here. The FX2 128-byte fix is the subtle one: the hang wasn't the size math, it was the unconditional `+1` making the buffer a non-multiple of `wMaxPacketSize` and suppressing the libusb short-packet terminator. Good catch on making it conditional on the Report ID tag actually being used. Reusing `windows/test/data/*.pp_data` for a cross-backend parity test is a nice consistency proof. ## Suggestions before merge 1. **Scope of "Fixes #274"** — this resolves the long-report truncation aspect, but #274 also asks for Full-Speed misconfiguration detection / reporting to the app. Consider softening to "Partially fixes" or adding a note. 2. **Platform length asymmetry** that @mcuee observed on Windows (libusb `wrote 130 / read 129` vs native HID `wrote 129 / read 128`) — worth a sentence in the PR body pointing to #731 so users don't re-file it as a regression. 3. Inline nits on specific lines below. Algorithm + spec alignment LGTM on the core change. --- Extended version: --- Comparison with the spec and other implementations HID 1.11 spec (§6.2.2.7 & §5.6 / §8): "If a Report ID tag is used anywhere in Report descriptor, all data reports for the device are preceded by a single byte ID field." Report ID = 0 is a placeholder meaning "no report IDs". Reports are sized as Σ(report_count × report_size) bits, rounded up to bytes. The PR's algorithm and the conditional +report_id_used byte match the spec exactly. Windows ([HIDP_CAPS](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidpi/ns-hidpi-_hidp_caps)): InputReportByteLength/OutputReportByteLength/FeatureReportByteLength — these always include the Report-ID byte (value 0 when unused). That's the source of the read/write-length platform asymmetry and is exactly what follow-up issue #731 is about. The PR's test case subtracts 1 byte from these values when ReportID == 0x00 to reconcile with the libusb convention (see parse_max_input_report_size in max_input_report_size_test.c). Linux kernel ([drivers/hid/hid-core.c](https://elixir.bootlin.com/linux/latest/source/drivers/hid/hid-core.c)): Uses the same algorithm. hid_add_field() accumulates report->size += parser->global.report_size * parser->global.report_count. In hid_register_report(), if (id != 0) report_enum->numbered = 1;. In hid_report_raw_event, when numbered is true the first data byte is consumed as the ID (cdata++; csize--;). Size is bounded by max_buffer_size - 1 bits when numbered. This is structurally identical to what the PR does — so the PR's approach is directly validated by the reference kernel implementation. hidapi/linux (hidraw backend): Avoids parsing entirely — delegates to the kernel: read(dev->device_handle, data, length) with user-supplied length, because the kernel has already sized the per-report buffer. That's why hidraw "just works" for the 128-byte FX2 firmware and why the libusb backend is the outlier. Strengths Correct algorithm. Matches HID 1.11 and Linux kernel's parsing exactly, including the subtle conditional Report-ID byte. Good test coverage via reuse of 25 real-world Windows pp_data fixtures — this is a nice cross-backend consistency proof. Safe fallback to input_ep_max_packet_size when the descriptor is corrupt/unparseable — no regression risk for devices already working. Fixes the classic "exact multiple of max packet size hangs" libusb gotcha — the conditional +1 was the critical insight; without it devices with payloads that happen to be multiples of 64 would hang forever waiting for a short packet. Remaining concerns worth flagging on review Re-read of report descriptor. hidapi_initialize_device now calls hid_get_report_descriptor_libusb during init (new control transfer on every open). This is a second descriptor fetch in addition to any caller-driven hid_get_report_descriptor(). Consider caching. HID_API_MAX_REPORT_DESCRIPTOR_SIZE buffer on stack (4096 bytes typically). [libusb/hid.c:1314](vscode-webview://1fvgisb5bmcc1dq4oe91o6bb0s5t72c0p53ijlpo93oa0ldi0koo/libusb/hid.c) in the diff allocates this on the stack — acceptable, but worth noting for embedded targets. cur_size reset timing. In the parser, cur_size is reset on each Report ID encounter. For descriptors that interleave INPUT/OUTPUT items between Report ID changes this is correct; just note that the max_size comparison happens only at Report-ID boundaries and at the end — which matches the spec semantics where each Report ID opens a fresh report namespace. Platform-length asymmetry (mcuee's Windows observation) is intentionally out of scope — tracked in #731. Worth linking from the PR description. PR description still says "Fixes #274" but #274 has broader asks (detection of USB Full-Speed misconfiguration, speed reporting to app). This PR fixes the "long reports get truncated" aspect; the speed/error-reporting aspect remains open. Typo in test comment (.dpt_desc → .rpt_desc) in libusb/test/CMakeLists.txt. Bottom line The PR is technically sound, aligned with HID 1.11 and the Linux kernel reference, and has been hardware-validated on Linux, FreeBSD and Android. The earlier "doesn't work" reports were a spec-compliance bug in the Report-ID handling that sudobash1 fixed. Primary blockers now are administrative: final Youw approval + merge, plus perhaps addressing the minor concerns above. The broader cross-platform length-consistency question is correctly deferred to [#731](https://github.com/libusb/hidapi/issues/731). --- _Drafted with Claude Code._
libusb/hid.c
Youw (Migrated from github.com) commented 2026-04-19 14:58:52 -05:00

Two minor things in this block:

  1. 4 KiB on the stack (HID_API_MAX_REPORT_DESCRIPTOR_SIZE) — fine for desktop, may be tight on some embedded targets. Worth heap-allocating to match the rest of the backend.
  2. This is now a second descriptor fetch per hid_open (one here, and another whenever a caller later invokes hid_get_report_descriptor()). Consider caching the bytes on hid_device so both consumers share them.
Two minor things in this block: 1. 4 KiB on the stack (`HID_API_MAX_REPORT_DESCRIPTOR_SIZE`) — fine for desktop, may be tight on some embedded targets. Worth heap-allocating to match the rest of the backend. 2. This is now a second descriptor fetch per `hid_open` (one here, and another whenever a caller later invokes `hid_get_report_descriptor()`). Consider caching the bytes on `hid_device` so both consumers share them.
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
Youw (Migrated from github.com) commented 2026-04-19 14:58:52 -05:00

Two typos: dpt_desc → rpt_desc, and rescriptor → descriptor.

Two typos: `dpt_desc` → `rpt_desc`, and `rescriptor` → `descriptor`.
Youw commented 2026-04-19 15:01:01 -05:00 (Migrated from github.com)

This is the result of the review by Claude Opus 4.7 (locally).

This is the result of the review by Claude Opus 4.7 (locally).
👍 2
Youw (Migrated from github.com) reviewed 2026-04-19 15:02:47 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2026-04-19 15:02:47 -05:00

1 - totally dismiss, 4KB is fine on any platform where HIDAPI shall be considered to be used

1 - totally dismiss, 4KB is fine on any platform where HIDAPI shall be considered to be used
Youw (Migrated from github.com) reviewed 2026-04-19 15:02:59 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2026-04-19 15:02:58 -05:00

2 - minor

2 - minor
JoergAtGithub commented 2026-04-19 16:48:37 -05:00 (Migrated from github.com)

PR description still says "Fixes #274" but #274 has broader asks (detection of USB Full-Speed misconfiguration, speed reporting to app). This PR fixes the "long reports get truncated" aspect; the speed/error-reporting aspect remains open.

I think this statement is not correct. The USB standard specifies the max read size per speed category. With this PR every read size should work and therefore every USB speed.

> PR description still says "Fixes #274" but #274 has broader asks (detection of USB Full-Speed misconfiguration, speed reporting to app). This PR fixes the "long reports get truncated" aspect; the speed/error-reporting aspect remains open. I think this statement is not correct. The USB standard specifies the max read size per speed category. With this PR every read size should work and therefore every USB speed.
👍 3
mcuee commented 2026-04-24 05:30:43 -05:00 (Migrated from github.com)

This is the result of the review by Claude Opus 4.7 (locally).

@Youw

Nice reviews. Just want to check if I read the comments correctly.

  1. This PR is in general okay.
  2. The platform related length discrepancy can be delayed to Issue #731.

In that case, I think this PR can be merged.

> This is the result of the review by Claude Opus 4.7 (locally). @Youw Nice reviews. Just want to check if I read the comments correctly. 1) This PR is in general okay. 2) The platform related length discrepancy can be delayed to Issue #731. In that case, I think this PR can be merged.
👍 1 ❤️ 1 🎉 1
mcuee commented 2026-04-24 23:38:25 -05:00 (Migrated from github.com)

Latest test results with hidapi git.

This PR is OK.

Windows

PS C:\work\libusb\hidapitester> .\hidapitester_git_winapi.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

PS C:\work\libusb\hidapitester> .\hidapitester_git_libusb.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

PS C:\work\libusb\hidapitester> .\hidapitester_pr728_libusb_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

FreeBSD

mcuee@freebsdvm:~/build/hidapitester $ sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,
9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58
,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,
106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

mcuee@freebsdvm:~/build/hidapitester $ sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,
8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,10
5,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

mcuee@freebsdvm:~/build/hidapitester $ sudo usbconfig
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.1: <OHCI root HUB Apple> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen1.2: <EZ-USB FX2 HID USBHIDIO Lakeview Research> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA)

mcuee@freebsdvm:~/build/hidapitester $ sudo lsusb -vvv -d 0925:1234

Bus /dev/usb Device /dev/ugen1.2: ID 0925:1234 Lakeview Research
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0925 Lakeview Research
  idProduct          0x1234
  bcdDevice            0.00
  iManufacturer           1 CYPRESS
  iProduct                2 EZ-USB FX2 HID USBHIDIO
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          3
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               80mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
          Report Descriptor: (length is 52)
            Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440
                            (null)
            Item(Local ): Usage, data= [ 0x01 ] 1
                            (null)
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage, data= [ 0x02 ] 2
                            (null)
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441
                            (null)
            Item(Local ): Usage, data= [ 0x03 ] 3
                            (null)
            Item(Local ): Usage, data= [ 0x04 ] 4
                            (null)
            Item(Global): Logical Minimum, data= [ 0x80 ] 128
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Physical Minimum, data= [ 0x00 ] 0
            Item(Global): Physical Maximum, data= [ 0xff ] 255
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x80 ] 128
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Local ): Usage, data= [ 0x05 ] 5
                            (null)
            Item(Local ): Usage, data= [ 0x06 ] 6
                            (null)
            Item(Global): Logical Minimum, data= [ 0x80 ] 128
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Physical Minimum, data= [ 0x00 ] 0
            Item(Global): Physical Maximum, data= [ 0xff ] 255
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x80 ] 128
            Item(Main  ): Output, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         4
  bNumConfigurations      1
can't get debug descriptor: Input/output error
Device Status:     0x0002
  (Bus Powered)
  Remote Wakeup Enabled
Latest test results with hidapi git. This PR is OK. Windows ``` PS C:\work\libusb\hidapitester> .\hidapitester_git_winapi.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device PS C:\work\libusb\hidapitester> .\hidapitester_git_libusb.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device PS C:\work\libusb\hidapitester> .\hidapitester_pr728_libusb_new.exe --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ``` FreeBSD ``` mcuee@freebsdvm:~/build/hidapitester $ sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8, 9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58 ,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105, 106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device mcuee@freebsdvm:~/build/hidapitester $ sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7, 8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57, 58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,10 5,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device mcuee@freebsdvm:~/build/hidapitester $ sudo usbconfig ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <OHCI root HUB Apple> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen1.2: <EZ-USB FX2 HID USBHIDIO Lakeview Research> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (80mA) mcuee@freebsdvm:~/build/hidapitester $ sudo lsusb -vvv -d 0925:1234 Bus /dev/usb Device /dev/ugen1.2: ID 0925:1234 Lakeview Research Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0925 Lakeview Research idProduct 0x1234 bcdDevice 0.00 iManufacturer 1 CYPRESS iProduct 2 EZ-USB FX2 HID USBHIDIO iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 (Bus Powered) MaxPower 80mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 52 Report Descriptor: (length is 52) Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440 (null) Item(Local ): Usage, data= [ 0x01 ] 1 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Local ): Usage, data= [ 0x02 ] 2 (null) Item(Main ): Collection, data= [ 0x00 ] 0 Physical Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441 (null) Item(Local ): Usage, data= [ 0x03 ] 3 (null) Item(Local ): Usage, data= [ 0x04 ] 4 (null) Item(Global): Logical Minimum, data= [ 0x80 ] 128 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Global): Physical Minimum, data= [ 0x00 ] 0 Item(Global): Physical Maximum, data= [ 0xff ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x80 ] 128 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage, data= [ 0x05 ] 5 (null) Item(Local ): Usage, data= [ 0x06 ] 6 (null) Item(Global): Logical Minimum, data= [ 0x80 ] 128 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Global): Physical Minimum, data= [ 0x00 ] 0 Item(Global): Physical Maximum, data= [ 0xff ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x80 ] 128 Item(Main ): Output, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 4 bNumConfigurations 1 can't get debug descriptor: Input/output error Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled ```
mcuee commented 2026-04-25 04:09:27 -05:00 (Migrated from github.com)

Latest results under Linux.

This PR is okay.

mcuee  …/hidapitester   main ?    v15.2.0  17:06  sudo ./hidapitester_git_hidraw --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  17:07  sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  17:07  sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device
Latest results under Linux. This PR is okay. ``` mcuee  …/hidapitester   main ?   v15.2.0  17:06  sudo ./hidapitester_git_hidraw --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device mcuee  …/hidapitester   main ?   v15.2.0  17:07  sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device mcuee  …/hidapitester   main ?   v15.2.0  17:07  sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ```
Youw (Migrated from github.com) reviewed 2026-04-25 06:40:42 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +43,4 @@
)
foreach(TEST_CASE ${HID_REPORT_DESCRIPTOR_TEST_CASES})
set(TEST_PP_DATA "${CMAKE_CURRENT_LIST_DIR}/../../windows/test/data/${TEST_CASE}.pp_data")
Youw (Migrated from github.com) commented 2026-04-25 06:40:42 -05:00

#796

#796
Youw commented 2026-04-25 06:44:20 -05:00 (Migrated from github.com)

This PR is okay.

There is still a number of unresolved comments across the code. Need to either handle or a reason to dismiss, before merge this. (Or move out into separate issue/ticket.

> This PR is okay. There is still a number of unresolved comments across the code. Need to either handle or a reason to dismiss, before merge this. (Or move out into separate issue/ticket.
👍 1
mcuee commented 2026-04-30 23:34:44 -05:00 (Migrated from github.com)

No regression for the following HID device under Linux (with non-Zero Input/Output/Feature reports IDs).
https://github.com/mcuee/picusb/tree/master/lvr_genhid_mod

mcuee  …/hidapitester   main ?    v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6  --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 05 06
Reading up to 3-byte input report, 250 msec timeout...read 3 bytes:
 01 05 06
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6  --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 05 06
Reading up to 3-byte input report, 250 msec timeout...read 3 bytes:
 01 05 06
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-feature 3,5,6  --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 3-byte feature report...wrote 3 bytes:
 03 05 06
Reading 3-byte feature report, report_id 4...read 3 bytes:
 04 05 06
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  12:32  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-feature 3,5,6  --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 3-byte feature report...wrote 3 bytes:
 03 05 06
Reading 3-byte feature report, report_id 4...read 3 bytes:
 04 05 06
Closing device
No regression for the following HID device under Linux (with non-Zero Input/Output/Feature reports IDs). https://github.com/mcuee/picusb/tree/master/lvr_genhid_mod ``` mcuee  …/hidapitester   main ?   v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6 --read-input Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 02 05 06 Reading up to 3-byte input report, 250 msec timeout...read 3 bytes: 01 05 06 Closing device mcuee  …/hidapitester   main ?   v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6 --read-input Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 02 05 06 Reading up to 3-byte input report, 250 msec timeout...read 3 bytes: 01 05 06 Closing device mcuee  …/hidapitester   main ?   v15.2.0  12:31  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-feature 3,5,6 --read-feature 4 Opening device, vid/pid: 0x0925/0x7001 Writing 3-byte feature report...wrote 3 bytes: 03 05 06 Reading 3-byte feature report, report_id 4...read 3 bytes: 04 05 06 Closing device mcuee  …/hidapitester   main ?   v15.2.0  12:32  sudo ./hidapitester_pr728_libusb --vidpid 0925:7001 --open --buflen 64 -l 3 --send-feature 3,5,6 --read-feature 4 Opening device, vid/pid: 0x0925/0x7001 Writing 3-byte feature report...wrote 3 bytes: 03 05 06 Reading 3-byte feature report, report_id 4...read 3 bytes: 04 05 06 Closing device ```
mcuee commented 2026-05-01 00:08:56 -05:00 (Migrated from github.com)

No regression under Windows either.

Minor modification needs to be used to get hidapitester to build with hidapi git or this PR, using libusb backend.

PS C:\work\libusb\hidapi_pr728_new> git diff
diff --git a/libusb/hid.c b/libusb/hid.c
index aabe462..fc2f7e5 100644
--- a/libusb/hid.c
+++ b/libusb/hid.c
@@ -34,8 +34,8 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/ioctl.h>
-#include <sys/utsname.h>
+//#include <sys/ioctl.h>
+//#include <sys/utsname.h>
 #include <fcntl.h>
 #include <wchar.h>

Using WinUSB driver.

$ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6  --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 05 06
Reading up to 3-byte input report, 250 msec timeout...read 3 bytes:
 01 05 06
Closing device

$ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6  --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 05 06
Reading up to 3-byte input report, 250 msec timeout...read 3 bytes:
 01 05 06
Closing device

$ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 3,5,6  --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 03 05 06
Reading 3-byte feature report, report_id 4...read 3 bytes:
 04 05 06
Closing device

$ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 3,5,6  --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 03 05 06
Reading 3-byte feature report, report_id 4...read 3 bytes:
 04 05 06
Closing device
No regression under Windows either. Minor modification needs to be used to get hidapitester to build with hidapi git or this PR, using libusb backend. ``` PS C:\work\libusb\hidapi_pr728_new> git diff diff --git a/libusb/hid.c b/libusb/hid.c index aabe462..fc2f7e5 100644 --- a/libusb/hid.c +++ b/libusb/hid.c @@ -34,8 +34,8 @@ #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> -#include <sys/ioctl.h> -#include <sys/utsname.h> +//#include <sys/ioctl.h> +//#include <sys/utsname.h> #include <fcntl.h> #include <wchar.h> ``` Using WinUSB driver. ``` $ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6 --read-input Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 02 05 06 Reading up to 3-byte input report, 250 msec timeout...read 3 bytes: 01 05 06 Closing device $ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 2,5,6 --read-input Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 02 05 06 Reading up to 3-byte input report, 250 msec timeout...read 3 bytes: 01 05 06 Closing device $ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 3,5,6 --read-feature 4 Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 03 05 06 Reading 3-byte feature report, report_id 4...read 3 bytes: 04 05 06 Closing device $ ./hidapitester_pr728_libusb.exe --vidpid 0925:7001 --open --buflen 64 -l 3 --send-output 3,5,6 --read-feature 4 Opening device, vid/pid: 0x0925/0x7001 Writing output report of 3-bytes...wrote 3 bytes: 03 05 06 Reading 3-byte feature report, report_id 4...read 3 bytes: 04 05 06 Closing device ```
JoergAtGithub commented 2026-05-06 16:16:05 -05:00 (Migrated from github.com)

@sudobash1 It would be great if you could address the lost open comments in the code review.

@sudobash1 It would be great if you could address the lost open comments in the code review.
👍 1
JoergAtGithub commented 2026-07-17 13:32:59 -05:00 (Migrated from github.com)

@sudobash1 It would be great if you could address the last remaining comments in this PR.

@sudobash1 It would be great if you could address the last remaining comments in this PR.
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:07 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2026-07-30 17:37:06 -05:00

Addressed in 39e58ae and the follow-up hardening commits. Codex moved the parser into the private libusb/hidapi_libusb_report_descriptor.h header and added libusb/test/max_input_report_size_test.c. The test suite now runs against all 25 Windows report-descriptor fixtures, compares computed input/output/feature lengths with the corresponding .pp_data, and includes focused malformed and boundary cases.

Generated by Codex (GPT-5.6 Sol).

Addressed in `39e58ae` and the follow-up hardening commits. Codex moved the parser into the private `libusb/hidapi_libusb_report_descriptor.h` header and added `libusb/test/max_input_report_size_test.c`. The test suite now runs against all 25 Windows report-descriptor fixtures, compares computed input/output/feature lengths with the corresponding `.pp_data`, and includes focused malformed and boundary cases. Generated by Codex (GPT-5.6 Sol).
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:08 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
Youw (Migrated from github.com) commented 2026-07-30 17:37:08 -05:00

Addressed. The libusb tests now read each <name>_real.rpt_desc fixture—not _expected.rpt_desc—and support the three formats present in the existing data: hid-decode R: records, normalized 0xNN lists, and trailing hexadecimal dumps. Expected report lengths continue to come from the matching .pp_data.

Generated by Codex (GPT-5.6 Sol).

Addressed. The libusb tests now read each `<name>_real.rpt_desc` fixture—not `_expected.rpt_desc`—and support the three formats present in the existing data: `hid-decode` `R:` records, normalized `0xNN` lists, and trailing hexadecimal dumps. Expected report lengths continue to come from the matching `.pp_data`. Generated by Codex (GPT-5.6 Sol).
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:09 -05:00
Youw (Migrated from github.com) left a comment

After latest fixes from codex - this needs to be tested

After latest fixes from codex - this needs to be tested
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:10 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2026-07-30 17:37:09 -05:00

Addressed. get_max_report_size() now returns signed ssize_t results: -1 for malformed descriptors, 0 when the requested report type is absent, and a positive byte count on success. Missing Report Size/Count state, truncation, overflow, invalid Report IDs, and unsafe sizes are rejected, with regression coverage in the parser self-test.

Generated by Codex (GPT-5.6 Sol).

Addressed. `get_max_report_size()` now returns signed `ssize_t` results: `-1` for malformed descriptors, `0` when the requested report type is absent, and a positive byte count on success. Missing Report Size/Count state, truncation, overflow, invalid Report IDs, and unsafe sizes are rejected, with regression coverage in the parser self-test. Generated by Codex (GPT-5.6 Sol).
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:11 -05:00
CMakeLists.txt
Youw (Migrated from github.com) commented 2026-07-30 17:37:11 -05:00

Addressed in the current branch. The libusb parser tests are registered through HIDAPI_WITH_TESTS; the Linux shared CMake job configures with -DHIDAPI_WITH_TESTS=ON and runs ctest --output-on-failure. The same test registration was also verified locally in strict C, C++, sanitizer, and modeled FreeBSD configurations.

Generated by Codex (GPT-5.6 Sol).

Addressed in the current branch. The libusb parser tests are registered through `HIDAPI_WITH_TESTS`; the Linux shared CMake job configures with `-DHIDAPI_WITH_TESTS=ON` and runs `ctest --output-on-failure`. The same test registration was also verified locally in strict C, C++, sanitizer, and modeled FreeBSD configurations. Generated by Codex (GPT-5.6 Sol).
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:12 -05:00
libusb/test/CMakeLists.txt
@ -0,0 +1,59 @@
add_executable(max_input_report_size_test max_input_report_size_test.c)
Youw (Migrated from github.com) commented 2026-07-30 17:37:12 -05:00

Addressed. The test documentation and paths consistently use rpt_desc and “descriptor”; neither dpt_desc nor “rescriptor” remains in the libusb test sources.

Generated by Codex (GPT-5.6 Sol).

Addressed. The test documentation and paths consistently use `rpt_desc` and “descriptor”; neither `dpt_desc` nor “rescriptor” remains in the libusb test sources. Generated by Codex (GPT-5.6 Sol).
Youw (Migrated from github.com) reviewed 2026-07-30 17:37:13 -05:00
libusb/hid.c
Youw (Migrated from github.com) commented 2026-07-30 17:37:13 -05:00

Addressed for item 2. A successfully fetched report descriptor is cached on hid_device and reused by hid_get_report_descriptor(), avoiding the second control transfer. The cache is cleared between failed alternate-setting initialization attempts and freed with the device. As discussed in this thread, the 4 KiB stack buffer was intentionally retained.

Generated by Codex (GPT-5.6 Sol).

Addressed for item 2. A successfully fetched report descriptor is cached on `hid_device` and reused by `hid_get_report_descriptor()`, avoiding the second control transfer. The cache is cleared between failed alternate-setting initialization attempts and freed with the device. As discussed in this thread, the 4 KiB stack buffer was intentionally retained. Generated by Codex (GPT-5.6 Sol).
mcuee commented 2026-08-06 21:16:04 -05:00 (Migrated from github.com)

Let me carry out some tests later (probably this weekend or next week).

Let me carry out some tests later (probably this weekend or next week).
mcuee commented 2026-08-13 04:59:23 -05:00 (Migrated from github.com)

Tested under Ubuntu Linux 26.04. This PR is good.

Test firmware here.
https://github.com/mcuee/picusb/tree/master/lvr_genhid/fx2hid_128bytes_report/fx2hid_128bytes

mcuee  …/hidapitester   main ?    v15.2.0  17:53  ls
./   .git/     .gitignore  CMakeLists.txt  Makefile         Makefile_pr728.libusb  docs/           hidapitester_git_hidraw*  hidapitester_pr728_libusb*  tests/
../  .github/  .vscode/    LICENSE         Makefile.libusb  README.md              hidapitester.c  hidapitester_git_libusb*  test_hardware/

mcuee  …/hidapitester   main ?    v15.2.0  17:55  sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 64 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  17:56  sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device

mcuee  …/hidapitester   main ?    v15.2.0  17:57  sudo ./hidapitester_git_hidraw --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128  --read-input
Opening device, vid/pid: 0x0925/0x1234
Writing output report of 129-bytes...wrote 129 bytes:
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
 80
Reading up to 129-byte input report, 250 msec timeout...read 128 bytes:
 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80
 00
Closing device
Tested under Ubuntu Linux 26.04. This PR is good. Test firmware here. https://github.com/mcuee/picusb/tree/master/lvr_genhid/fx2hid_128bytes_report/fx2hid_128bytes ``` mcuee  …/hidapitester   main ?   v15.2.0  17:53  ls ./ .git/ .gitignore CMakeLists.txt Makefile Makefile_pr728.libusb docs/ hidapitester_git_hidraw* hidapitester_pr728_libusb* tests/ ../ .github/ .vscode/ LICENSE Makefile.libusb README.md hidapitester.c hidapitester_git_libusb* test_hardware/ mcuee  …/hidapitester   main ?   v15.2.0  17:55  sudo ./hidapitester_git_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 64 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Closing device mcuee  …/hidapitester   main ?   v15.2.0  17:56  sudo ./hidapitester_pr728_libusb --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device mcuee  …/hidapitester   main ?   v15.2.0  17:57  sudo ./hidapitester_git_hidraw --vidpid 0925:1234 --open --buflen 256 -l 129 --send-output 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128 --read-input Opening device, vid/pid: 0x0925/0x1234 Writing output report of 129-bytes...wrote 129 bytes: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 Reading up to 129-byte input report, 250 msec timeout...read 128 bytes: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 00 Closing device ```
This pull request is broken due to missing fork information.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin 'sudobash1/libusb_input_size:sudobash1/libusb_input_size'
git switch 'sudobash1/libusb_input_size'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'master'
git merge --no-ff 'sudobash1/libusb_input_size'
git switch 'sudobash1/libusb_input_size'
git rebase 'master'
git switch 'master'
git merge --ff-only 'sudobash1/libusb_input_size'
git switch 'sudobash1/libusb_input_size'
git rebase 'master'
git switch 'master'
git merge --no-ff 'sudobash1/libusb_input_size'
git switch 'master'
git merge --squash 'sudobash1/libusb_input_size'
git switch 'master'
git merge --ff-only 'sudobash1/libusb_input_size'
git switch 'master'
git merge 'sudobash1/libusb_input_size'
git push origin 'master'
Sign in to join this conversation.
Reviewers
No reviewers
JoergAtGithub
Labels
Clear labels   
3rdparty
3rd-party related issue/question

  
Android
Android OS related

  
API
API change, Version 1 stuff

  
Author does not respond

   
bsd
FreeBSD, NetBSD, OpenBSD, etc

  
bug
Something isn't working

  
build system/CI
Anything related to building the project or running on CI

  
ci-virtual-device
Run the virtual HID device CI jobs (Windows driver + libusb raw-gadget)

  
CMake
Related to CMake build system

  
Contributions Welcome
Any external help is welcome

  
Core
Related to common codes like hidapi.h

  
dependencies
Pull requests that update a dependency file

  
device-specific
Issues/PRs related to a specific device

  
documentation
Improvements or additions to documentation

  
don't_merge
Don't merge this PR as is

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
Example
Related to hidtest or new examples

  
Haiku
Related to Haiku OS (using libusb backend)

  
hidraw
Related to Linux/hidraw backend

  
hotplug
Related to hotplug

  
info required
Need more input from PR/issue author

  
invalid
Not a HIDAPI issue

  
libusb
Related to libusb backend

  
macOS
Related to macOS backend

  
Misc
Typo, whitespace, etc.

  
Not an issue

   
question
Information is requested

  
Release
Related to new release

  
Test
Related to built-in test (not hidtest)

  
Test GUI
Related to a Test GUI application

  
Windows
Related to Windows backend

  
wontfix
This will not be worked on

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
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libusb/hidapi!728
No description provided.