Why does libusb Library block in the interface libusb_interrupt_transfer?

Question

I could send the data to a usb device successfully, but the response from the devices fails every time. I'm sure the endpoint is correct due to the successful communications with the same devices by using the hid api from windows.

Here is my code:

struct libusb_context*  hContxt;

libusb_init(&hContxt);

libusb_set_debug(hContxt, LIBUSB_LOG_LEVEL_DEBUG);

libusb_device_handle*   hUsbHandle = libusb_open_device_with_vid_pid(hContxt, 0x0483, 0x3021);;

if (NULL == hUsbHandle)
{
    printf("open failed!\n");
    return 0;
}

libusb_claim_interface(hUsbHandle, 0);

int _nMaxPackSize = libusb_get_max_packet_size(libusb_get_device(hUsbHandle), 0x01);

unsigned char _szCmd[1024] = "12355666";
int _nSendSuccessLen = 0;

int _nRet = libusb_interrupt_transfer(hUsbHandle, 0x01,\
    const_cast<unsigned char*>(&_szCmd[0]), _nMaxPackSize, &_nSendSuccessLen, 200);

unsigned char recv[1024];
int     recvExpectLen = 0;
int     recvAcutalLen = 0;

_nMaxPackSize = libusb_get_max_packet_size(libusb_get_device(hUsbHandle), 0x81);

while(1)
{
    memset(recv, 0x00, sizeof recv);

    _nRet = libusb_interrupt_transfer(hUsbHandle, 0x81,\
        const_cast<unsigned char*>(recv), _nMaxPackSize, &recvAcutalLen, 1000);//block in libusb_handle_events_timeout_completed.

    if (_nRet == LIBUSB_SUCCESS)
    {
        printf("recv Len: %d\n", recvAcutalLen);
    }

    Sleep(1000);
}

Do I need to set sth with the others api of libusb?

The debug information of libusb as follows:

[ 0.811201] [00000820] libusb: debug [hid_submit_bulk_transfer] matched endpoint
 81 with interface 0
[ 0.811201] [00000820] libusb: debug [hid_submit_bulk_transfer] reading 65 bytes
 (report ID: 0x00)
[ 0.826801] [00000820] libusb: debug [libusb_get_next_timeout] next timeout in 0
.982700s
[ 0.826801] [00000820] libusb: debug [libusb_handle_events_timeout_completed] do
ing our own event handling
[ 0.842401] [00000820] libusb: debug [handle_events] poll fds modified, reallocating
[ 0.842401] [00000820] libusb: debug [handle_events] poll() 2 fds with timeout i
n 983ms
[ 1.840803] [00000820] libusb: debug [handle_events] poll() returned 0
[ 1.840803] [00000820] libusb: debug [libusb_cancel_transfer] transfer 00474628
[ 1.872003] [00000820] libusb: debug [hid_abort_transfers] will use interface 0<br/>
[ 1.887603] [00000820] libusb: warning [hid_abort_transfers] cancel failed: [6]
句柄无效。<br/>
[ 1.918803] [00000820] libusb: debug [libusb_cancel_transfer] cancel transfer failed error -5
[ 1.918803] [00000820] libusb: warning [handle_timeout] async cancel failed -5 errno=0
[ 1.918803] [00000820] libusb: debug [libusb_get_next_timeout] no URB with timeo
ut or all handled by OS; no timeout!
[ 1.918803] [00000820] libusb: debug [libusb_handle_events_timeout_completed] do
ing our own event handling
[ 1.934403] [00000820] libusb: debug [handle_events] poll() 2 fds with timeout i
n 60000ms

This looks suspicious `[libusb_cancel_transfer] transfer 00474628`? Is that related or due to an unrelated usb device? — David C. Rankin, Feb 05 '18 at 06:19
@DavidC.Rankin I'm sure that the transfer and file handle is the same in the R/W mode from debugging the program. — ZacharyLiu, Feb 05 '18 at 07:01
What prompted the question was it looks like you connected, read 65 bytes, then started to `poll` apparently with your call to `libusb_interrupt_transfer`, but then your string of failures occur. I'll have to look further, but it looks like libusb sets a timeout in its call to poll of 1-sec which would explain the blocking for 1-sec. I don't mess with USB, so I'm sorry I can't help further, but I think you need to confirm how it is calling `poll` (or `select` or whatever it is actually using) to see how it is setting itself up. — David C. Rankin, Feb 05 '18 at 07:44
@DavidC.Rankin Very thanks for your help. The blocking for 1-sec is the setting timeout for read. But the hid_abort_transfers cancel failed leads to make the usb handle invalid and the blocking timeout for 60-sec. I have tried to set the interval of poll, but it doesn't work. — ZacharyLiu, Feb 05 '18 at 07:58
@DavidC.Rankin Finally, I've found that this is a bug of libusb at the newst version. The content: hid_handle = handle_priv->interface_handle[current_interface].dev_handle at the windows_winusb.c Line: 3688. It should revise to hid_handle = handle_priv->interface_handle[current_interface].api_handle; — ZacharyLiu, Feb 06 '18 at 06:24
Hah! good for you. I actually downloaded `libusb` and was working with it to lean a bit more about the issue, but ran out of steam before I got there. Make sure you file the issue with [libusb](https://github.com/libusb/libusb) so that it can be fixed. — David C. Rankin, Feb 06 '18 at 06:32
@DavidC.Rankin I've written the email to the developer of libusb to fix the bug. Hope them to fix it in time. — ZacharyLiu, Feb 06 '18 at 08:08
In the mean time you can grab the libusb source, make a patch that implements the needed changes and compile your own package to verify the changes (the libusb devs would probably be very grateful for a patch `:)`. I've had to do this a number of times for Gtk+2 and various other libraries. (nothing like the 27 minute build time for a full libgkt+2.0..., just twiddle your thumbs and watch the lines of compilation goo fly by...) — David C. Rankin, Feb 06 '18 at 08:54
Easy way is to unpack the source into a directory. The find the file you need to modify (say `./libusb/src/somedir/foo.c`) then create a temp dir to hold a copy of the file. (if you are multiple files, I just recreate the path to the files (e.g. `./tmp/libusb/src/somedir/`) and copy the files you want to change there. Change the files under `tmp`, then create a patch (e.g. `cd ./tmp` and `diff -uNr --label libusb/src/somedir/foo.c ../../libusb/src/somedir/foo.c libusb/somedir/src/foo.c > ../../foo_c_fix.patch`. Then add the `patch` command to the build script. — David C. Rankin, Feb 07 '18 at 01:59
Good job. I lost track of the thousands of bugs I've filed. (on kde4 debut during 2008 accounted for over 280 alone). But this is the nuts-and-bolts of the open source community. Those that are willing to participate are what open source is. Thanks. — David C. Rankin, Feb 10 '18 at 09:43

Why does libusb Library block in the interface libusb_interrupt_transfer?

0 Answers0