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

sudobash1 · 2025-03-25T20:27:04Z

Currently the libusb version of hidapi simply reads up to wMaxPacketSize bytes as the report. This is problematic when reports are longer than wMaxPacketSize. The current behavior will split that report up.

The proper solution is to review the report descriptor to find the longest input report and use that as the length of the libusb_fill_interrupt_transfer buffer. (Note: there is no need to manually get multiple USB packets and concatenate them together to fit the report length. USB already handles that for us.)

This will still work for HID devices when some input reports are shorter than others. The HID device will just send a short packet terminator and libusb will give us the shorter buffer.

The substance of these changes is in the get_max_input_size method. It uses the same basic report descriptor parsing as get_usage. I considered changing the code so that there could be shared parsing code, but I decided that was overkill for this.

Fixes #274

sudobash1 · 2025-03-25T22:08:47Z

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

Be-ing · 2025-03-26T01:07:51Z

Thank you for finally taking care of this longstanding bug.

Youw

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

Fixes libusb#274

JoergAtGithub · 2025-03-26T18:21:25Z

libusb/hid.c

+   Requires an opened device with *claimed interface*.
+
+   The return value is the size on success and -1 on failure. */
+static size_t get_max_input_size(libusb_device_handle *handle, int interface_num, uint16_t expected_report_descriptor_size)


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:

hidapi/windows/test/data/045E_02FF_0005_0001.pp_data

Line 21 in 0ab6c14

pp_data->caps_info[0]->ReportByteLength = 16

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.

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.

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?)

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.

@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:

hidapi/windows/hidapi_winapi.h

Line 68 in 0ab6c14

int HID_API_EXPORT_CALL hid_winapi_descriptor_reconstruct_pp_data(void *hidp_preparsed_data, unsigned char *buf, size_t buf_size);

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

hidapi/windows/hidapi_descriptor_reconstruct.c

Line 181 in 0ab6c14

int hid_winapi_descriptor_reconstruct_pp_data(void *preparsed_data, unsigned char *buf, size_t buf_size)

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.

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.

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:

hidapi/windows/test/data/046A_0011_0006_0001.pp_data

Lines 16 to 19 in 0ab6c14

pp_data->caps_info[0]->FirstCap = 0

pp_data->caps_info[0]->LastCap = 2

pp_data->caps_info[0]->NumberOfCaps = 2

pp_data->caps_info[0]->ReportByteLength = 9

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

hidapi/windows/test/data/046A_0011_0006_0001.pp_data

Lines 37 to 38 in 0ab6c14

pp_data->cap[0]->BitSize = 1

pp_data->cap[0]->ReportCount = 8

hidapi/windows/test/data/046A_0011_0006_0001.pp_data

Lines 83 to 84 in 0ab6c14

pp_data->cap[1]->BitSize = 8

pp_data->cap[1]->ReportCount = 6

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?

mcuee · 2025-03-27T05:12:38Z

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

hidapi/windows/test/data/046A_0011_0006_0001.pp_data

Line 4 in 0ab6c14

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

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

JoergAtGithub · 2025-03-27T06:17:16Z

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.

JoergAtGithub · 2025-03-27T06:20:44Z

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

hidapi/windows/test/data/046A_0011_0006_0001.pp_data

Line 4 in 0ab6c14

dev->manufacturer_string = "dev->product_string = "dev->release_number = 0x0100
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.

mcuee · 2025-03-27T07:34:55Z

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.

pp_data_dump issue for 046A_0011_0006_0001 -- Lower Priority #729

JoergAtGithub · 2025-03-27T19:48:22Z

libusb/test/CMakeLists.txt

+     if(NOT EXISTS "${TEST_PP_DATA}")
+          message(FATAL_ERROR "Missing '${TEST_PP_DATA}' file for '${TEST_CASE}' test case")
+     endif()
+     set(TEST_EXPECTED_DESCRIPTOR "${CMAKE_CURRENT_LIST_DIR}/../../windows/test/data/${TEST_CASE}_expected.rpt_desc")


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.

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?

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

JoergAtGithub · 2025-03-27T19:49:30Z

libusb/hid.c

+			if (report_count < 0 || report_size < 0) {
+				/* We are missing size or count. That isn't good. */
+				return 0;


Suggested change

if (report_count < 0 || report_size < 0) {

/* We are missing size or count. That isn't good. */

return 0;

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

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).

Makes sense!

sudobash1 · 2025-03-27T20:00:14Z

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 · 2025-03-27T20:10:00Z

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?

Youw · 2025-03-28T10:31:54Z

CMakeLists.txt

@@ -70,8 +70,8 @@ if(HIDAPI_ENABLE_ASAN)
    endif()
 endif()

-if(WIN32)
-    # so far only Windows has tests
+if(WIN32 OR HIDAPI_WITH_LIBUSB)


also need to update builds.yml

Youw · 2025-03-28T10:34:48Z

libusb/test/CMakeLists.txt

+     add_test(NAME "LibUsbHidMaxInputReportSizeTest_${TEST_CASE}"
+          COMMAND max_input_report_size_test "${TEST_PP_DATA}" "${TEST_EXPECTED_DESCRIPTOR}"
+          WORKING_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}"
+          #WORKING_DIRECTORY "$<TARGET_FILE_DIR:hidapi_winapi>"


Suggested change

#WORKING_DIRECTORY "$<TARGET_FILE_DIR:hidapi_winapi>"

Youw · 2025-03-28T10:35:37Z

libusb/test/CMakeLists.txt

+set(CMAKE_VERSION_SUPPORTS_ENVIRONMENT_MODIFICATION "3.22")
+
+foreach(TEST_CASE ${HID_DESCRIPTOR_RECONSTRUCT_TEST_CASES})
+     set(TEST_PP_DATA "${CMAKE_CURRENT_LIST_DIR}/../../windows/test/data/${TEST_CASE}.pp_data")


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

Youw

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 · 2025-03-28T10:39:49Z

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: #731

mcuee · 2025-03-28T14:46:09Z

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.

HID reports of more than 64 bytes and libusb backend #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

mcuee · 2025-03-28T14:50:44Z

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 · 2025-03-29T18:20:37Z

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.

mcuee · 2025-03-30T00:19:38Z

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 · 2025-03-30T03:11:55Z

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 · 2025-04-01T00:01:36Z

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 · 2025-04-01T05:13:46Z

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 · 2025-04-02T01:38:36Z

@Be-ing and @JoergAtGithub

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

mcuee · 2025-04-02T01:49:20Z

@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.

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

mcuee · 2025-04-03T01:31:25Z

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.

sudobash1 mentioned this pull request Mar 25, 2025

HID reports of more than 64 bytes and libusb backend #274

Open

sudobash1 force-pushed the libusb_input_size branch from 068fd62 to 52c6cd9 Compare March 25, 2025 22:06

mcuee added bug Something isn't working libusb Related to libusb backend labels Mar 26, 2025

Youw reviewed Mar 26, 2025

View reviewed changes

libusb/hid.c Outdated Show resolved Hide resolved

Properly determine libusb read size for large reports

fe758f9

Fixes libusb#274

JoergAtGithub reviewed Mar 26, 2025

View reviewed changes

mcuee mentioned this pull request Mar 27, 2025

pp_data_dump issue for 046A_0011_0006_0001 -- Lower Priority #729

Open

Fixes to report size calculation and added tests

8949182

sudobash1 force-pushed the libusb_input_size branch from 52c6cd9 to 2708264 Compare March 27, 2025 19:36

Allow computation of max report size for other types

3710895

sudobash1 force-pushed the libusb_input_size branch from 2708264 to 3710895 Compare March 27, 2025 19:42

Don't assign -1 to size_t. That's silly

470c9e9

JoergAtGithub suggested changes Mar 27, 2025

View reviewed changes

Youw reviewed Mar 28, 2025

View reviewed changes

Youw mentioned this pull request Mar 28, 2025

Store Input/Output/Feature reports sizes for all platforms #731

Open

This was referenced Apr 1, 2025

libusb backend for Windows and macOS #319

Open

Add hidraw backend for FreeBSD #730

Open

mcuee mentioned this pull request Apr 3, 2025

arch Linux github action build failed #732

Closed

	pp_data->caps_info[0]->FirstCap = 0
	pp_data->caps_info[0]->LastCap = 2
	pp_data->caps_info[0]->NumberOfCaps = 2
	pp_data->caps_info[0]->ReportByteLength = 9

	pp_data->cap[0]->BitSize = 1
	pp_data->cap[0]->ReportCount = 8

	pp_data->cap[1]->BitSize = 8
	pp_data->cap[1]->ReportCount = 6

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

Are you sure you want to change the base?

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

Conversation

sudobash1 commented Mar 25, 2025 • edited Loading

sudobash1 commented Mar 25, 2025

Be-ing commented Mar 26, 2025

Youw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcuee commented Mar 27, 2025 • edited Loading

JoergAtGithub commented Mar 27, 2025

JoergAtGithub commented Mar 27, 2025

mcuee commented Mar 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JoergAtGithub Mar 27, 2025 • edited Loading

Choose a reason for hiding this comment

sudobash1 commented Mar 27, 2025

JoergAtGithub commented Mar 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Youw left a comment

Choose a reason for hiding this comment

Youw commented Mar 28, 2025

mcuee commented Mar 28, 2025 • edited Loading

mcuee commented Mar 28, 2025

sudobash1 commented Mar 29, 2025

mcuee commented Mar 30, 2025 • edited Loading

mcuee commented Mar 30, 2025 • edited Loading

mcuee commented Apr 1, 2025

mcuee commented Apr 1, 2025

mcuee commented Apr 2, 2025

mcuee commented Apr 2, 2025 • edited Loading

mcuee commented Apr 3, 2025

sudobash1 commented Mar 25, 2025 •

edited

Loading

mcuee commented Mar 27, 2025 •

edited

Loading

JoergAtGithub Mar 27, 2025 •

edited

Loading

mcuee commented Mar 28, 2025 •

edited

Loading

mcuee commented Mar 30, 2025 •

edited

Loading

mcuee commented Mar 30, 2025 •

edited

Loading

mcuee commented Apr 2, 2025 •

edited

Loading