libusb_control_transfer size is incorrect when using default report ID (only windows port)

[gorlik]

I am using a HID USB device with only one report type. The descriptor does not contain any report ID as described in the USB spec.

In windows calling libusb_control_transfer for either IN or OUT results in packets short by 1 byte (the data is not shifted, just missing the last byte).
below is a sample call of the function:
libusb_control_transfer(devh, CTRL_IN, HID_GET_REPORT, (HID_REPORT_TYPE_FEATURE<<8), 0, buffer, BUFFER_SIZE, TIMEOUT);

The exact same source and USB device work just fine using libusb in linux.
Also, very similar code works in both linux and windows when the HID device has report IDs.

[xiaofan]

Please post the debug log. I think there is a problem here in the HID backend. A debug log will help to identify the problem.

Also I will switch to email for further discussions. Please follow up in the libusb mailing list if you can.

[pbatard]

My tests show this problem as a regression that was introduced by pbr301 (commit id 35f01dd9b1763d73b61f362e21ffea6f7248530f). I'm still looking into it.

[gorlik]

thanks for the quick responses.
I have confirmed that the pre-built pbr299 from the libusb.org wiki is working as expected.
pbr301 is the first non working one.

I attached the log files generated using level 7 for both pbr299 and pbr301.
as far as I can tell there are 2 significant differences:

• pbr301 uses _hid_get/set_feature instead of _hid_get/set_report
• pbr301 reports actual_lenght=3 instead of 4 (4 is the value passed to the libusb_control_transfer call)

I also verified that the issue affects transfers in both directions not just the device to host as described in the ticket summary.

[pbatard]

Should be fixed in pbr313.

The problem is that DeviceIoControl?() does not include the report ID in the returned read/write size, when report IDs are zero (i.e when report IDs are not in use), despite the fact that the report ID is effectively included in the payload sent/received.

[gorlik]

I tried the precompiled pbr314. Unfortunately, it cannot find the device at all (log attached).
I suspect this is related to the new enumeration algorithm introduce in pbr311.

[xiaofan]

Yes this assertion means there are still problems with the new enumeration code. Please upload the full debug log. The ones you uploaded are not complete.

[pbatard]

Yes, this is an issue linked to the new enumeration method and unrelated to the previous one. The code is still hardwired to bail out on any assertion failure, in order to make sure people tell us if there are issues.

The problem is here:

libusb:error [windows_get_device_list] program assertion failed: unlisted parent for '\.USB#VID_0424&PID_2503#6&E496CF6&0&1'

With the device above being a hub.
Now, from the previous logs, the configuration of your machine should be as follows, as far as USB hubs are concerned:

2 root hubs:

• libusb:debug [usb_enumerate_hub] 10 ports Hub: \.USB#ROOT_HUB20#4&53D5&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
• libusb:debug [usb_enumerate_hub] 10 ports Hub: \.USB#ROOT_HUB#4&2E9141BE&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}

2 standard hubs (connected to the first root hub):

• libusb:debug [usb_enumerate_hub] 3 ports Hub: \.USB#VID_0424&PID_2504#5&3072DE82&0&4#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
• libusb:debug [usb_enumerate_hub] 3 ports Hub: \.USB#VID_0424&PID_2503#6&E496CF6&0&1#{F18A0E88-C30C-11D0-8815-00A0C906BED8}

From the new enum log it looks like the parents hubs for \.USB#VID_0424&PID_2503#6&E496CF6&0&1 have been enumerated as expected...:

• libusb:debug [init_device] (bus: 2, addr: 255, depth: 0, port: 0): '\.USB#ROOT_HUB#4&2E9141BE&0'
• libusb:debug [init_device] (bus: 1, addr: 255, depth: 0, port: 0): '\.USB#ROOT_HUB20#4&53D5&0'

...by the time we enumerate the non-root hubs, so I don't have a clear idea yet as to why the parent lookup seems to fail.

I'll have to produce a version of libusb with additional debug messages to try to get more insight into that. I would suggest that we continue this troubleshooting this problem on the mailing list, since it's not related to the original issue, as it's a lot more convenient. If you could send an e-mail there indicating which of the MS or MinGW binaries you use, I should be able to produce custom binaries for you to test within 24 hours.

[pbatard]

Since I haven't heard back from you, I just put a version of lsusb online with the additional debug (MS, Win32). Can you please run it and send the log? You can download it from ​this link

[gorlik]

I sent an email to the mailing list last week, but I don't see my reply nor I received a bounce.

Anyway, the log you requested is:
libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIo? for I/O cancellation
libusb:debug [windows_clock_gettime_threaded] hires timer available (Frequency: 2000060000 Hz)
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [usbi_htab_create] using 1021 entries hash table
libusb:debug [libusb_get_device_list]
libusb:debug [windows_get_device_list] PROCESSING HCDs {3ABF6F2D-71C4-462A-8A92-1E6861E6AF27}
libusb:debug [windows_get_device_list] PRO: \.PCI#VEN_10DE&DEV_056A&SUBSYS_73661462&REV_A1#3&267A616A&0&21 (devinst: 800)
libusb:debug [windows_get_device_list] allocating new device for session [C6]
libusb:debug [windows_get_device_list] PRO: \.PCI#VEN_10DE&DEV_07FE&SUBSYS_73661462&REV_A1#3&267A616A&0&20 (devinst: 880)
libusb:debug [windows_get_device_list] allocating new device for session [282]
libusb:debug [windows_get_device_list] PROCESSING HUBs {F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [windows_get_device_list] PRO: \.USB#ROOT_HUB#4&2E9141BE&0 (devinst: 900)
libusb:debug [get_parent_session_id] parent devinst: 880
libusb:debug [get_parent_session_id] parent: PCIVEN_10DE&DEV_07FE&SUBSYS_73661462&REV_A13&267A616A&0&20
libusb:debug [windows_get_device_list] parent session_id: 282
libusb:debug [windows_get_device_list] allocating new device for session [218]
libusb:debug [init_device] (bus: 2, addr: 255, depth: 0, port: 0): '\.USB#ROOT_HUB#4&2E9141BE&0'
libusb:debug [windows_get_device_list] PRO: \.USB#ROOT_HUB20#4&53D5&0 (devinst: 938)
libusb:debug [get_parent_session_id] parent devinst: 800
libusb:debug [get_parent_session_id] parent: PCIVEN_10DE&DEV_056A&SUBSYS_73661462&REV_A13&267A616A&0&21
libusb:debug [windows_get_device_list] parent session_id: C6
libusb:debug [windows_get_device_list] allocating new device for session [29]
libusb:debug [init_device] (bus: 1, addr: 255, depth: 0, port: 0): '\.USB#ROOT_HUB20#4&53D5&0'
libusb:debug [windows_get_device_list] PRO: \.USB#VID_0424&PID_2503#6&E496CF6&0&1 (devinst: 96C)
libusb:debug [get_parent_session_id] parent devinst: 9B8
libusb:debug [get_parent_session_id] parent: USBVID_0424&PID_25045&3072DE82&0&4
libusb:debug [windows_get_device_list] parent session_id: 329
libusb:error [windows_get_device_list] program assertion failed: unlisted parent for '\.USB#VID_0424&PID_2503#6&E496CF6&0&1'
libusb:debug [libusb_unref_device] destroy device 1.0
libusb:debug [libusb_unref_device] destroy device 2.0
libusb:debug [libusb_unref_device] destroy device 2.255
libusb:debug [libusb_unref_device] destroy device 1.255

also, I think I should open another ticket to track this since it is a separate issue.

[xiaofan]

I think it is good to open another ticket.
As for the post to the mailing list, I think you may need to subscribe to the mailing list.

[xiaofan]

BTW, I still believe it is much easier to use mailing list for such issues. Please subscribe to the mailing list and then start the discussion.

[pbatard]

Before you open a new issue, can you try pbr315 which I pushed yesterday? As I didn't see any log from you, and I suspect the issue has to do with Windows not listing hubs in root to leaf order, I included a patch in pbr315 that should alleviate the issue.

If you download the latest binary archive from ​here and run something like "xusb -x -d" (the pre-built xusb executable is located in the examples/ directory), it should provide some debug logging of the enumeration and let us know if the assertion failure is still there.

[pbatard]

Expected to have been fixed in previous iterations of HID, the implementation of which has since been removed => closed as no longer valid.