ControlTransfer and device descriptor

[nikola-matic]

What is the flow when doing control transfers, and is it possible to fetch interface/endpoint descriptors (tacking on to my previous issue #48)?

If this is in fact possible (at least it should be given the USB spec), let's analyze a simpler example, and assume that I'm trying to fetch the device descriptor (let's also assume that UsbDk_GetDevicesList doesn't exist).

Per spec, this should be done by doing a control transfer read to endpoint zero (0), and sending an 8 byte request that should look like this 80 06 00 01 00 00 12 00 (values are hexadecimal).

0x80 indicates a device to host direction and device as recepient 0x06 GET_DESCRIPTOR request 0x01 indicates that we'd like a device descriptor 0x12 indicates that 18 bytes of data should be retrieved (size of device descriptor)

The code used to issue a control read request looks like this:

PUSB_DK_TRANSFER_REQUEST transferRequest = (PUSB_DK_TRANSFER_REQUEST)malloc(sizeof(tag_USB_DK_TRANSFER_REQUEST));
LPOVERLAPPED overlapped = NULL;
DWORD error; 

transferRequest->TransferType = ControlTransferType;
transferRequest->EndpointAddress = 0x00;
transferRequest->Buffer = (PVOID64)malloc(8);
*(LONG64*)transferRequest->Buffer = 0x0012000001000680;
transferRequest->BufferLength = 8;
transferRequest->IsochronousPacketsArraySize = 0;
transferRequest->IsochronousPacketsArray = NULL;

TransferResult result = Device::api.ReadPipe()(deviceHandle_, transferRequest, overlapped);

When I issue this request, it completes successfully, i.e. result variable indicates a TransferSuccess, as does UsbdStatus in GenResult. However, BytesTransferred in GenResult is 0, indicating that no bytes were transferred in the request.

Is this this proper flow? Should I execute more reads after this? All in all, the questions is as previously mentioned - is it possible to fetch the device descriptor (and analogously configuration/interface/endpoint) descriptors by doing control transfer, instead of using the API functions? Thanks for having patience.

[sameehj]

What is the flow when doing control transfers, and is it possible to fetch interface/endpoint descriptors (tacking on to my previous issue #48)?

It is indeed possible

When I issue this request, it completes successfully, i.e. result variable indicates a TransferSuccess, as does UsbdStatus in GenResult. However, BytesTransferred in GenResult is 0, indicating that no bytes were transferred in the request. Is this this proper flow? Should I execute more reads after this? All in all, the questions is as previously mentioned - is it possible to fetch the device descriptor (and analogously configuration/interface/endpoint) descriptors by doing control transfer, instead of using the API functions? Thanks for having patience.

There is absolutely no problem with using control transfers instead of the given API, however this is not a proper flow, you should get a valid response with data and BytesTransferred shouldn't be zero. I think you have a bug/bugs lying somewhere in your code, the first one I noticed is the request value:

(LONG64)transferRequest->Buffer = 0x0012000001000680; I think you mistyped the request, it should be: 0x0012000000100680 instead.

[nikola-matic]

@sameehj, I don't think I miss typed it, as I get 0xffffffff80000800 error when I use your value, which is USBD_STATUS_INTERNAL_HC_ERROR if I'm not mistaken. When I use my value, I get status OK (0). Now, having looked into UsbDk code, I'm assuming that CUsbDkRedirectorStrategy::DoControlTransfer function is called when doing a control transfer, and in it, ControlTransferAsync seems to be called to do the transfer itself. Could it be that I have to check for the transferred bytes later if the transfer is done asynchronously?

[sameehj]

@sameehj, I don't think I miss typed it, as I get 0xffffffff80000800 error when I use your value, which is USBD_STATUS_INTERNAL_HC_ERROR if I'm not mistaken. When I use my value, I get status OK (0). Now, having looked into UsbDk code, I'm assuming that CUsbDkRedirectorStrategy::DoControlTransfer function is called when doing a control transfer, and in it, ControlTransferAsync seems to be called to do the transfer itself. Could it be that I have to check for the transferred bytes later if the transfer is done asynchronously?

@nikola-matic Sorry for the long reply I've been a bit busy lately. You are right indeed, you need to poll and check for the completion using the function UsbDk_GetRedirectorSystemHandle() (https://github.com/daynix/UsbDk/blob/master/UsbDkHelper/UsbDkHelper.h#L251)

Please refer to UsbDk's code in Libusb for an example of the usage. You can find that here: https://github.com/libusb/libusb/blob/master/libusb/os/windows_usbdk.c Checkout the functions usbdk_do_control_transfer, usbdk_do_bulk_transfer and usbdk_do_iso_transfer.

[nikola-matic]

@sameehj, no worries. In fact, I realized that libusb does in fact offer the capabilities that I need (it doesn't "support" libusb_claim_interface & libusb_detach_kernel_driver calls on Windows and Darwin, which was a no no, since that's exactly what I needed - but then, looking through their code, I realized that they call UsbDk_StartRedirect in libusb_open).

In any case, I'll be using libusb with UsbDk backend instead of UsbDk directly. Thanks for the help, and I'll look into writing a simple example for redirecting a device (e.g. mouse) and doing interrupt reads from it. Thanks again!

[sameehj]

Great! Since this issue is resolved I am closing it, feel free to re open it if you think otherwise or create a new issue if needed :)

[sameehj]

Great! Since this issue is resolved I am closing it, feel free to re open it if you think otherwise or create a new issue if needed :)