Skip to content

(untested) Signal overlapped from caller in LUsb0_ControlTransfer #33

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

Conversation

tormodvolden
Copy link
Contributor

This is an attempt to deal with libusb 1.0.24 or later which always uses
asynchronous control transfers. libusb will pass an OVERLAPPED structure and
use this afterwards to check that the transfer has finished.

The transfer will still be forced synchronous here, but by
signalling the finished transfer the caller will not be reporting
timeouts for actual finished transfers.


Additional merge request comments:
I am not sure if this is correct, if it compiles, or if it solves any problem. There is however some timeouts showing up in libusb, for example in libusb/libusb#94 (comment) which I could possibly think is caused by this.

The libusbK.sys backend deals properly with both sync and async requests. The libusb0.sys backend would up to now ignore the overlapped for an async request. I think the rework in libusb 1.0.24 made everything async. The suggested change makes it "fake async". Probably it could be made to work again with libusb changes instead, but I think offering a "fake async" here is good anyway.

Alternatively the overlapped from the caller can be passed down to the DeviceIOControl instead of the extra overlapped currently created in _usb_io_sync(). I will suggest this in another merge request. It still doesn't make it true async. I think the repacking done in usb_control_msg() requires allocating a new buffer for setup + outgoing data, and it is not obvious for me how to free that buffer at the right point in time later, if going asynchronous.

This is an attempt to deal with libusb 1.0.24 or later which always uses
asynchronous control transfers. It will pass an OVERLAPPED structure and
use this afterwards to check that the transfer has finished.

It will still be forced into a synchronous transfer here, but by
signalling the finished transfer the caller will not be reporting
timeouts for actual finished transfers.

Signed-off-by: Tormod Volden <[email protected]>
@mcuee mcuee added the libusb0.sys specific to libusb0.sys backend of libusbk.dll label Oct 30, 2021
@mcuee
Copy link
Owner

mcuee commented Oct 30, 2021

@TravisRo Hi Travis, please take a look when you got the time. Thanks.

@tormodvolden
Copy link
Contributor Author

tormodvolden commented Oct 30, 2021

One thing that might be missing is passing the number of bytes read/written back to the caller through the overlapped. I remember seeing in someone's log files that completed transfers always were listed with 0 length, it was probably a similar issue.

In libusb windows_force_sync_completion() does

overlapped->Internal = (ULONG_PTR)STATUS_SUCCESS;
overlapped->InternalHigh = (ULONG_PTR)size;

but it also calls PostQueuedCompletionStatus() so maybe my one-liner SetEvent() above is not enough.

@tormodvolden
Copy link
Contributor Author

It seems that we were able to fix this in libusb instead without too much trouble, so I will close this "hot fix" merge request which probably is questionable anyway. I will keep #34 open, which I think makes more sense, at least as an RFC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libusb0.sys specific to libusb0.sys backend of libusbk.dll
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants