Why control_in_blocking for my UVC device returns Err(Cancelled) on Windows
#43
-
|
I think nusb is cool, so I'm willing to replace I'm pretty sure that the following parameters work, with respect to the framework of rusb/libus. However, they failed with nusb. let request = 0x86;
let wvalue = 0x0100;
let windex = 0x01;
let timeout = std::time::Duration::from_secs(1);
let mut buf = [0; 50];rusb /* with rusb, these parameters work */
let size = device_handle
.read_control(request_type, request, wvalue, windex, &mut buf, timeout)
.unwrap(); nusb /* with nusb, these parameters fails*/
let control = Control {
control_type: ControlType::Class,
recipient: Recipient::Interface,
request: request,
value: wvalue,
index: windex,
};
let result = interface.control_in_blocking(control, &mut buf, timeout);I've replaced the driver of my usb device to Could you give me some guidlines to get over it? Thank you very much. logUpdated
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
|
The log It's hard to tell why that would be different than rusb, though. One limitation to be aware of is that with |
Beta Was this translation helpful? Give feedback.
-
|
Yes, my usb device has 2 interfaces indeed. I think Thanks for the very accurate guideline. UpdateAfter testing, it seems sad that for control_type in [ControlType::Class, ControlType::Standard, ControlType::Vendor ] {
for recipient in [ Recipient::Device, Recipient::Endpoint, Recipient::Interface, Recipient::Other ] {
for index in 0..=2 {
if let Ok(_) = wrap_nusb_control_in_blocking(control_type, recipient, &device, &interface, index) {
panic!()
}
}
}
}
// <----- can reach hereThanks anyway. I can't figure the problem out till now. Maybe I have to investigate it by debugging into the device's hardware code later. But please tell me if you have any suggestions based on the device information updated in the question. |
Beta Was this translation helpful? Give feedback.
-
|
Hi! After investigated, my problem appears to be related to two low-level issues.
Would you consider resolving these two issues at |
Beta Was this translation helpful? Give feedback.
-
I'm not sure what you mean by "stream request". Do you mean different bmRequestType values resulting leading to different branches in the setup packet handler as I discuss below? With nusb, the bmRequestType is calculated from the
This is the limitation I was referring to previously. In #45 I added documentation and log a warning when this occurs. Note that this also applies with libusb and rusb if you are using the WinUSB driver and pass a Are you sure you want It's part of the USB standard that the the If you control the firmware, you could make it use |
Beta Was this translation helpful? Give feedback.
-
Emm... I think Yes, I mean the UVC-specific request can be detected by firmware, when using
Yes you're right, and you've mentioned it before. But I wonder if it is essentially related to issue 1 (UVC-specific request). But seems that I took an inappropriate example, and I'd like to have taken another example
Yes, I can control the firmware and change its inner logic. Actually, I'm not expert in USB standard but a user at best, so I'm not sure what is its should-be state, and I'd appreciate the discussion and the guideline you've provided. But what made me most confused is the interoperability. In fact, for developping the firmware of the device (UVC device), several common video played (e.g. the OS out-of-the-box video player, PotPlayer, and ffmpeg) were used to test and check the interoperability. The device firmware has passed the check. Note that in this stage, there's no programmed software nor user-installed driver. Only default uvc drivers/frameworks (such as MSMF, DirectShow, V4L2) were used. So I assume that, after this stage, the firmware logic is compatible with uvc standard. Then later, I focused on Windows and found that the OS framework (MSMF and DirectShow) seemed to be less performant since frames would drop/miss every hundreds of frames. So I turned to the way of reading raw data of usb and decoding w.r.t uvc. To achieve this, I installed After these stages, the uvc device turns out to be has interoperability with all these common players and libusb-win32 driver. So I feel strange why it would fail with WinUSB. Doesn't the Windows-default uvc driver not depend on Windows-default usb driver WinUSB? However, although I assume the firmware should better keep its current state to keep interoperability, I still tested modifying its inner logic to accept any DEBUG nusb::platform::windows_winusb::enumeration: Driver is "WinUSB"
INFO nusb::platform::windows_winusb::device: Blocking control In, 50 bytes
INFO nusb::platform::windows_winusb::device: Blocking control In, 50 bytes
INFO nusb::platform::windows_winusb::device: Blocking control In, 50 bytes
INFO nusb::platform::windows_winusb::device: Blocking control Out, 34 bytes
INFO nusb::platform::windows_winusb::device: Blocking control In, 50 bytes
INFO nusb::platform::windows_winusb::device: Blocking control Out, 34 bytes
DEBUG nusb::platform::windows_winusb::transfer: Submit transfer 0x1985f385790 on endpoint 83 for 102400 bytes IN
DEBUG nusb::platform::windows_winusb::transfer: Submit transfer 0x1985f385610 on endpoint 83 for 102400 bytes IN
DEBUG nusb::platform::windows_winusb::transfer: Handling completion for transfer 0x1985f385790
DEBUG nusb::platform::windows_winusb::transfer: Submit transfer 0x1985f3857f0 on endpoint 83 for 102400 bytes IN
DEBUG nusb::platform::windows_winusb::transfer: Handling completion for transfer 0x1985f385610
DEBUG nusb::platform::windows_winusb::transfer: Transfer 0x1985f385790 on endpoint 83 failed: 87, 0 bytes transferredAt last, although |
Beta Was this translation helpful? Give feedback.
-
|
Ah, ok, didn't realize that it was UVC. By "control" and "stream" you were also referring to the You should I think UVC will have an interface association descriptor that groups together those two interfaces. That makes Windows see them as a single interface group, and as a result, you might have a problem with nusb If your whole device (rather than specific interface) is bound to WinUSB, #41 may help, because in nusb 0.1.6 it was only looking at the first interface in that case. I'll release 0.1.7 with that fix soon. Yes, since it is UVC, you should follow the standard, though since you control the firmware you could e.g. make it accept either recipient=Device OR recipient=Interface if you needed to. The Windows UVC kernel driver is not built on WinUSB. WinUSB is a kernel driver whose purpose is to expose the device functionality to userspace for a driver written as a regular application instead of in kernel mode. I'd expect the kernel UVC driver to be faster than doing it in userspace with nusb or rusb, and you'd generally want to use the kernel mode driver for classes like UVC where one exists. Typically UVC uses isochronous endpoints, which are not currently implemented in nusb (though are supported in WinUSB as of Windows 10). Are your endpoints bulk or isochronous? Isochronous might prevent you from using nusb for now. If it is bulk, and since it looks like you are submitting 3+ transfers (which is the correct way to optimize performance) the performance difference between libusb0 and WinUSB drivers might be due to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much. My understanding goes deeper along with your knowledge. --
Yes, so my uvc device uses bulk transfer other than isochronous to seek for wider compatibility. I just tried to
It sounds great! I expect one day this |
Beta Was this translation helpful? Give feedback.
-
Yeah, #41 doesn't actually fix this like I hoped it would. Opened #48 for this. |
Beta Was this translation helpful? Give feedback.
Ah, ok, didn't realize that it was UVC. By "control" and "stream" you were also referring to the
VideoControlandVideoStreaminginterfaces defined in the UVC specification. In your descriptor you posted above, your interface number 0 has subclass=1 so is the VideoControl interface, and your interface number 1 has subclass=2 so is the VideoStreaming interface.You should
claim_interface(0)andclaim_interface(1)to open both of these interfaces, and makeVideoControlrequests using interface 0, andVideoStreamingrequests using interface 1. Then WinUSB will set the least significant byte of index to 0 or 1 to match the interface number used.I think UVC will have an interface association …