-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Emscripten: MAX_CTRL_BUFFER_LENGTH too big for some devices #1493
Comments
Shouldn't the code instead do like "everybody else"? First request a small part of the configuration (actually the configuration descriptor itself without all other descriptors) into a small buffer, in order to read the total length from the header, then request the exact total length. @RReverser |
We could do that - at the cost of extra round-trip cost for each configuration descriptor, which is somewhat unfortunate - but I'm surprised as neither in official docs of different operating systems nor in real-world usage I haven't encountered any OS which wouldn't accept even 4K packets. And I do use Windows 11, where apps using this backend worked just fine so far, so I'm really curious what the difference / why this example only accepts up to 256 bytes. Is it some kind of special USB device / some old protocol / anything else that might be relevant? |
It is not so much about the OS but the device, I suppose. See also the last paragraph here: https://blog.numist.net/post/3646027757/usb-deviceiocontrol-overlapped-io-and-you-and And I agree, we need to know what kind of device this is. An lsusb -v dump is always nice. |
Yes, looks to be device specific rather than OS. I tried other devices on Windows and they were fine with 4096. Also, I tried this device (an RTL SDR) on Chrome/Linux and it has the same problem when length greater than 255. lsusb output: Bus 002 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T |
I wonder if this is the actual limit - as in, 512 bytes would also work. If we can use wMaxPacketSize, then we don't really need to pay for 2x requests to read length and the actual descriptor for each config separately - we could just always use this limit instead. |
256 doesn't work, unfortunately. |
This is only per device enumeration so I wouldn't worry too much about an extra request. It is the way all host stacks do it, and as mentioned in my link above, many devices expect it do be done this way. I don't know if the standard says something specific about it. The whole concept here is very inefficient anyway. Somewhere down this convoluted stack the whole configuration has been cached already so any device request shouldn't have been needed. |
Huh, fascinating. Okay, if there is no way around it, let's do 2 requests. I'm not near a computer right now, so could do this later, but if you want to open a PR, I'd be happy to review. |
I’m trying to use libusb in a Qt WebAssembly app via the Emscripten port. The first call to libusb_get_device_list() is failing on Windows 11 using Chrome, Edge and Opera, with the console message:
Tracing through the code, I see that the first call to controlTransferIn works successfully (where wLength is 0x12), however the second controlTransferIn call fails where wLength is 0x1000).
I believe the problem relates to the following code in emscripten_webusb.cpp:
If I change this max buffer size to 255, then the second transfer works.
I was able to reproduce the same behavior using pure Javascript, as can be seen in the attached example: js.zip - so does indeed look like a browser/platform specific limit.
The text was updated successfully, but these errors were encountered: