-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ControlTransfer and device descriptor #49
Comments
It is indeed possible
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:
|
@sameehj, I don't think I miss typed it, as I get 0xffffffff80000800 error when I use your value, which is |
@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 |
@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! |
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 :) |
1 similar comment
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 :) |
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 recepient0x06
GET_DESCRIPTOR request0x01
indicates that we'd like a device descriptor0x12
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:
When I issue this request, it completes successfully, i.e.
result
variable indicates aTransferSuccess
, as doesUsbdStatus
inGenResult
. However,BytesTransferred
inGenResult
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.
The text was updated successfully, but these errors were encountered: