Better reference documentation on descriptors #75
Comments
|
I did get it working in the end for linux... still struggling to get windows to load the proper winusb setup (devices is listed in device manager - but chrome doesn't list it unless I force the Arduino 101 DFU driver on it). Progress so far: https://twitter.com/denladeside/status/818717316443676672 |
|
Lars: have you seen https://github.com/sowbug/weblight? If any code there
isn't sufficiently helpful, let me know what's confusing, and I'll try to
improve comments/docs.
…On Tue, Jan 10, 2017, 11:26 AM Lars Knudsen ***@***.***> wrote:
I did get it working in the end for linux... still struggling to get
windows to load the proper winusb setup (devices is listed in device
manager - but chrome doesn't list it unless I force the Arduino 101 DFU
driver on it). Progress so far:
https://twitter.com/denladeside/status/818717316443676672
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#75 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAB2VElBDRS5fILeFXRpfKjn-MS8RyPFks5rQ9twgaJpZM4Lfy_P>
.
|
|
Hi Mike, thanks. What I am currently struggling with is getting Windows 10 to load the correct (version?..setting along with?) winusb.sys for the WebUSB interface. It looks like it's loaded and ready in the device manager - but chrome doesn't find it. Then I de-install and re-install the driver, forcing the Arduino 101 DFU driver on it .. and all of a sudden it just works forever for that VID/PID combo. I have a feeling that I need to do more MS 2.0 descriptors or tweak something in either the BOS or the MS USB request replies (handshake)... but have not managed to get a device connect to consistently show itself as available in chrome on windows 10 (chrome 55, 56 and 57) |
|
@larsgk: Can you post what Chrome records under chrome://device-log/ ? |
|
@devanlai I know you are .... https://developer.mbed.org/users/larsgk/code/USBDevice_WebUSB/ ;) I think we (you and I) need to use MS 2.0 descriptors - not the 1.0 that you are currently using. It seems that the loading of a proper winusb.sys is flaky at best - not appearing (at worst = mostly). If I remove the MS descriptor part altogether and force the Arduino 101 DFU driver over my WebUSB interface (in my case, I have a CDC + WebUSB device), it seems to get listed in chrome. If I just select the std WinUSB from MS or put the WINUSB in the MS 1.0 descriptor, it doesn't work for me on win10 |
|
I'm actually working on a different project with WebUSB using MS 2.0 descriptors (which are kind of flakey on USB 3.0 ports, from what I've seen). I think I might have had the MS 1.0 descriptors working for WebUSB on Windows 7 at one point, but I was also only testing non-composite devices at that time. From my understanding, for composite devices WinUSB needs the DeviceInterfaceGUIDs registry key to be set on the interface, which can be done automatically the very first time the device is plugged in using the MS OS Descriptors or after the fact using an installer or a tool like Zadig. Try installing the WinUSB driver using Zadig and see if that helps. However, even with the DeviceInterfaceGUIDs key set, I've found that the BOS transfer fails on Windows 7, which I think is a Chrome implementation bug that I'll write up after I've investigated it a bit further. |
|
Interesting. Do you have an example that gets the right driver and
descriptors working for a CDC+WebUSB combo on win10? I have been fighting
this for a week :)
…On Jan 10, 2017 21:45, "Devan Lai" ***@***.***> wrote:
I'm actually working on a different project with WebUSB using MS 2.0
descriptors (which are kind of flakey on USB 3.0 ports, from what I've
seen). I think I might have had the MS 1.0 descriptors working for WebUSB
on Windows 7 at one point, but I was also only testing non-composite
devices at that time.
From my understanding, for composite devices WinUSB needs the
DeviceInterfaceGUIDs registry key to be set on the interface, which can be
done automatically the very first time
<https://github.com/pbatard/libwdi/wiki/WCID-Devices#Defining_a_Device_Interface_GUID_or_other_device_specific_properties>
the device is plugged in using the MS OS Descriptors or after the fact
using an installer or a tool like Zadig <http://zadig.akeo.ie/>.
Try installing the WinUSB driver using Zadig and see if that helps.
However, even with the DeviceInterfaceGUIDs key set, I've found that the
BOS transfer fails on Windows 7, which I think is a Chrome implementation
bug that I'll write up after I've investigated it a bit further.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA97loy2LuQ-Fqya6aRqfOCQake6x1mBks5rQ-4DgaJpZM4Lfy_P>
.
|
|
After some coding-by-permutation, I've found that moving my WebUSB/DFU interface up so that it's the first interface instead of the last one helps. On Windows 7, after installing the WinUSB driver with Zadig, it doesn't show the landing page notification, but I can select it from the device picker if I navigate to corresponding landing page. In both cases, the actual WebUSB control transfers work fine. |
|
@devanlai is it possible to mix 1.0 and 2.0 descriptors (in the same device?) I am banging my head against the wall here on windows... do you have some working descriptor snippets that I could take a peek at? I am also trying to figure out how and what to set for DeviceInterfaceGUIDs |
|
I managed to get a non breaking 2.0 descriptor sent (inspired by @sowbug 's code - thanks) it does seem to miss the DeviceInterfaceGUIDs part (what should that be set to? - and will this force the WinUSB driver on it... why is MS OS 1.0 not good enough?). It didn't install the WinUSB driver automatically and choosing the one shipped with windows ("update driver -> MS -> WinUSB generic) doesn't work (WINUSB (v10.0.10240.16384)). only after downgrading to the one shipped with Zadig (WinUSB (v6.1.7600.16385)) it seems to do the trick (or maybe it's the WCID ontop that does this?). /rant: Christ - it took me 1/2 day to get this running on linux .. why does MS have to make things so complicated :) |
|
I am beginning to suspect there is a bug (or 2) in chrome - related to WebUSB.
thoughts? |
|
Are you able to get the landing page notification popup, or is it only showing up in the device picker (and does it fetch the USB strings correctly)?. I just tested an older CDC+DFU WebUSB project that uses MS OS 1.0 descriptors. Moving the DFU interface around doesn't seem to make a difference. Whether the DFU interface is first or not still results in no landing page notification, working strings on Win7, broken strings on Win10. Downgrading the driver from v10.0 to v6.1 doesn't seem to make any difference. If you want to take a look for comparison: |
|
About the landing page notification: I think I heard it may have been
temporarily disabled on Windows. Not sure though as I have also only seen
it on Linux.
On Jan 11, 2017 6:42 PM, "Devan Lai" <notifications@github.com> wrote:
Are you able to get the landing page notification popup, or is it only
showing up in the device picker (and does it fetch the USB strings
correctly)?.
I just tested an older CDC+DFU WebUSB project that uses MS OS 1.0
descriptors. Moving the DFU interface around doesn't seem to make a
difference. Whether the DFU interface is first or not still results in no
landing page notification, working strings on Win7, broken strings on
Win10. Downgrading the driver from v10.0 to v6.1 doesn't seem to make any
difference.
If you want to take a look for comparison:
https://github.com/devanlai/termlink/blob/winusb/src/USB/winusb.c
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA97lg8IiJTMkbyDlUBcD9Ri0qqLW1wCks5rRRR5gaJpZM4Lfy_P>
.
|
|
Yes, landing page detection is disabled on Windows on Chrome startup due to a bug causing Chrome hangs for a small percentage of users. If you call any of the navigator.usb methods it will initialize Chrome's USB subsystem and you should start getting notifications when you connect a new device. |
|
@reillyeon , for actual buggy behavior in chrome (or differences between platforms), what are the main keywords to add on crbugs to be caught & who to CC? just WebUSB & you? |
|
@devanlai Hi again, I just published a first draft (will move it into the lib when works) of the WebUSBCDC class here: https://github.com/larsgk/empirikit-controller/blob/master/WebUSBCDC.cpp (please check if you are ok with the license - I'm not an expert in those things). The MS OS 1.0 extended properties block is the best I could come up with (GUID is just a random generated one... should it be?). It doesn't seem to do the trick still for Chrome on Windows - but Windows seems to not really complain about anything :-s |
|
@sowbug , @devanlai btw - I am trying to gather people (browser & hardware vendors, developers, spec'ers, .. ) with a common interest in getting hardware connected to the browser (usb, ble, other?) on https://things2browsers.slack.com for some holistic discussions and solutions in the area - PM me on @denladeside (twitter) for invite link if you're interested |
|
The license looks fine - I just went with Apache because it's what mbed uses. For testing if the WinUSB drivers are installed correctly, I recommend using the xusb example utility that's distributed with libusb. If it can't access your device, chances are that Chrome can't either, since Chrome uses an older libusbx backend for USB access. |
That should be reported as a bug - as it needs to use whatever APIs are available on windows to make the experience as smooth as possible. The device shows no errors when plugged in and I can also see all details using windows tools - just not with Chrome. (so maybe the descriptors were ok after all - even without the GUID ;)) |
|
Probably related: https://bugs.chromium.org/p/chromium/issues/detail?id=637404 |
Does this help? WCID is just another (more generic) name for MS descriptor based driver installation. You're talking about composite devices though... |
|
@pbatard Actually your documentation is much better than anything to be found on MSDN - but it never got to the point of pure PnP - most probably because of the bug I linked above. Most probably, we don't need to extended properties descriptors once libusb is fixed or Chrome uses the WinUSB APIs directly. |
|
I actually came here because of that bug report, as I have never found any evidence that specific versions of WinUSB cannot work with libusb, and my understanding is that Windows actively prevents downgrading of WinUSB driver files in the first place, so that Zadig driver installation shouldn't do much, compared to WCID, besides providing an explicit Especially, I don't see issues accessing a WCID device, using the latest libusb, on a brand new Windows 10 platform where the driver was installed automatically (without using Zadig): I also confirmed afterwards that Zadig did report the driver version to be |
|
@pbatard Looking at the libusb issue list, it's clear that there are some issues with libusb + the vanilla WinUSB driver: https://github.com/libusb/libusb/issues?q=is%3Aissue+is%3Aopen+label%3Awindows My current implementation is this: https://github.com/larsgk/empirikit-controller/blob/master/WebUSBCDC.cpp Both with and without the extended properties (I must somehow verify that they are actually requested - beginning to doubt it) - the built in WinUSB (and CDC for the other interface) driver is loaded automatically with no apparent issues in the device manager - but only after applying the older driver from Zadig, Chrome can communicate with the device. Maybe you can tell me if you see something obviously wrong in my code regarding the MS descriptors? If I get it working without any inf-file or forced driver through Zadig, I'll make sure to write a blog about it (for dummies like me ;)) so others will not have to go through the same pain. |
Not really. Most of these are opened by people who don't realize they need to install WinUSB to be able to communicate with their devices (or who try to do exotic things like accessing a virtual USB device). While I no longer follow the libusb mailing list actively, I have yet to recall any issue that had anything to with an incompatibility between libusb and the vanilla WinUSB driver. Which is why I'd be extremely surprised if you managed to identify one.
Do you also have the xusb report from your device (doesn't matter if it doesn't use the self-installed driver)? The source tells what you intend your reports to be, but nothing beats seeing what the device actually reports...
Which should basically equate to applying an inf file. The Now, you are using a composite device, so my bet is that your issue is linked to that. For one, I'm not sure if, when you are installing the Zadig driver, you are doing it on the composite parent, or on each interface. This can make a world of difference with regards to being able to access the device through libusb... I'll try to have a look at your code when I get a chance. |
Mine reports as being 6.xx after applying the driver. In any case - it seems like a bug (on the libusb/chrome side) when
If it's because some descriptor (or part of) is missing, I'd expect Windows to report back an error - as it does normally if anything is out of order with the descriptors. I am considering to do a small test using the vanilla setup I get (that doesn't work in chrome) - using the official WinUSB APIs from MS in stead of libusb. E.g. something in the area of https://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx . |
It's on the specific interface - the same as happens automatically with the device on first time, where:
|
That's because Zadig gets it from the I guess I could attempt to provide better version reporting in Zadig, as it can be misleading that this is only the version from the
Not really in the case of WCID. If the WCID descriptors are not set properly Windows won't complain, but you'll only get part of the process (which you then have to troubleshoot through the registry). However, when that happens, you wouldn't usually see the driver installed from Device Manager, which you do.
Okay. Then you might be running into an issue with composite devices and libusb. Composite interfaces have always been a pain in the ass on Windows, and something that took a long time to get working. As I wrote most of that code (but I am no longer involved in libusb development), I wouldn't be surprised if we're running into a corner case where libusb expects to see something (that would be set by a formal You may want to compare the libusb debug logs from xusb, when trying to access the device with the WCID driver, and when accessing the device with the Zadig driver. A diff may provide good clues as to what happens, and whether some more composite fixing is needed in libusb. |
|
@pbatard thanks for all the input. /rant IF I somehow finally get it working, I'll make sure to close the bugs (chrome, libusb and here) and point to the code and a blog post on how to get the (damn) thing working .. I can't be the only one ;) |
|
Agree with the pain. People also tend to bark at the complexity of the libusb code for Windows, but it's not like Microsoft really gave us developers any choice there... One more thing you may want to try, since that's the only major difference I can see with the WCID descriptors you define and the ones I have (which work with libusb, but then again, my device is not composite), is try to use I don't remember actually trying to set WCID for an actual composite device, so, while I currently expect the information I provide in the guide to work with those, there might still be some pieces missing... |
|
@mon: Note: make sure to adjust the interface numbers too when you move the interface descriptors, since Windows 10 is strict about interface descriptors appearing in order for USB 2.1/3.0 devices. |
|
Oh ho ho, this is very exciting after so many hours. I tried this yesterday in a sleep deprived state with no luck, but redoing it now (perhaps I forgot to move an endpoint number or 2) my libusb test program can write to my endpoint successfully. Works fine in Chrome, too! |
|
@mon you scared me. There steps to do that with arduino:
I do not have any buttons connected to arduino to verify HID but WebUSB works OK. |
|
For the interface sequence issue, yes there is currently a libusb Windows limitation with regard to IAD. This is the libusb github ticket. Patches are welcome. |
|
Any new info about why Chrome on windows does not use the string descriptors? My device is detected, but shown as "Unknown device". chrome://device-log also shows just empty strings. On Mac it's showing vendor and product strings in chrome://device-log and only the product name in the requestDevice popup. What's wrong with Windows? |
|
@Gamadril , last week, I finally managed to get 'zero-conf' on windows working with the help from multiple people. Apparently (not a big surprise) the MS documentation was missing and/or flawed on the issue. The last inspiration that helped make it work: intel/zephyr.js@b01cd51#diff-6c3813770d3a0724357a9be78c39123f My resulting firmware: https://github.com/empirikit/empirikit-controller/releases/tag/17.07.002 (including a change in the included lib here: https://developer.mbed.org/users/larsgk/code/USBDevice_WebUSB/rev/1d8a6665d607 I am currently creating some down to earth documentation that will end in a medium blog post + a web component to help on the client side. |
|
Thanks, I already have the DeviceGUIDs registry key in my descriptor, but get the unknown device shown. Actually the DeviceGUIDs is mandatory to get chrome detecting the device. Strange thing is also that it doesn't work with single string key DeviceGUID. It has to be multiline DeviceGUIDs... |
I looked into this a bit and it looks like a libusb issue - it specifically looks for a registry entry named "DeviceInterfaceGUIDs" and if it doesn't exist it ignores the device (at least for composite USB devices). I don't know why it looks for that key though, since it isn't required or even present by default - maybe because the Arduino driver had it?... |
|
Great find @Tronil |
|
I found in Chrome for Windows the flag #new-usb-backend
If activated, it seems that WebUSB works without any additional MS descriptors and separate WinUSB interfaces (I have only the CDC Interface with BOS descriptor). It even shows the right device name when requesting access to device like on a Mac. However anything else is not working on my machine - I get an "Access denied" exception when calling device.open(). |
|
@Gamadril it seems the new backend will replace libusb - but I think @reillyeon mentioned it doesn't support composite devices yet |
|
@reillyeon Thanks for the info. What are the plans for the future? Will the development on the new backend go on or the old one improved? Windows is the platform with most users, but also the one with the most WebUSB problems... |
|
@Gamadril Development of the new backend is ongoing. There is only so far we can go with the existing libusb one because it doesn't integrate well into the rest of the Chrome application. |
|
@Gamadril if you need help getting a solution working ASAP, feel free to ping me on twitter ( denladeside ) |
|
I came back to my WebUSB project after a long break. In the meantime WebUSB was activated in Chrome by default and got the "final" state. And I was very surprised that Chrome can now detect ALL available USB devices regardless if they "WebUSB" capable or not. My CDC devices work out of the box on Mac and Linux without any firmware modification. Is that the way it will work in the future? Because in the spec there is still a paragraph regarding the descriptors to make a device WebUSB capable. |
|
Hm. So it seems chrome on windows is still using the libusb backend with all the bugs mentioned here, right? :( |
|
@Runn1ng @Gamadril Even with the quirks needed - it's actually working quite ok (only tested on Windows 10): https://github.com/empirikit/empirikit-controller if you need help with something, |
Chrome WebUSB backend (libusb) needs GUIDs to work correctly. See https://github.com/pbatard/libwdi/wiki/WCID-Devices for GUIDs details. Also see discussion here WICG/webusb#75
|
@larsgk see trezor/trezor-mcu#260 Our problem is now we have first two interfaces as HID and want to turn on webusb as the third. However, Libusb on chrome windows somehow behaves strangely when it is not the first interface. That breaks integration into existing software, since many of those use a HID connection on a set first interface |
|
I can probably help you out - PM me on e.g. Twitter - @denladeside
…On Dec 9, 2017 19:14, "Karel Bílek" ***@***.***> wrote:
@larsgk <https://github.com/larsgk> see trezor/trezor-mcu#260
<trezor/trezor-mcu#260>
Our problem is now we have first two interfaces as HID and want to turn on
webusb as the third. However, Libusb on chrome windows somehow behaves
strangely when it is not the *first* interface. That breaks integration
into existing software, since many of those use a HID connection on a set
interface
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA97lmMdyyk-06xjndAWqCHv7c8Ly40fks5s-s3ogaJpZM4Lfy_P>
.
|
|
Chrome crashes on Windows 10 when WebUSB is second and HID is first. :( This is relevant Chrome crash report (it seems to be "restricted", I cannot un-restrict it). https://bugs.chromium.org/p/chromium/issues/detail?id=795804 |
|
I recently published this article to document all the descriptors developers need to care about for WebUSB-enabled devices: https://developers.google.com/web/fundamentals/native-hardware/build-for-webusb/ If there is anything missing that you think should be added please file an issue against the WebFundamentals repo and I'll revise the article. |
|
Oh wow a good article. I wanted to make a similar article myself, maybe more detailed about all the Windows 7 struggles (it took months to figure out all the strange Windows Update issues on Win7), but never managed to finish it. This article is good enough |
|
If I have time, I will add an issue with the win7 issues. It's not easy to get it working on win7 well (win8+ are working well, with the WinUSB compatible IDs). |
|
With this discussion, it still took me a long time to get WebUSB work with a USB composite device on Windows 10. What I learned is:
|
|
Good find. I need to look into getting handshaking working properly on
Windows for Zephyr firmware. Maybe I can reach out to you about that?
…On Wed, Feb 12, 2020, 15:45 Yihui Xiong ***@***.***> wrote:
With this discussion, it still took me a long time to get WebUSB work with
a USB composite device on Windows 10. What I learned is:
-
If using MS OS 2.0 descriptor, USB 2.1 or greater is required
Run lsusb -v -d {VID:PID} to check the USB version bcdUSB on Linux
-
If using MS OS 1.0 descriptor, we can use Zadig to downgrade WinUSB
[image: image]
<https://user-images.githubusercontent.com/948283/74344961-4db9e000-4de8-11ea-90ec-d0bd2b0dcc7c.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75?email_source=notifications&email_token=AAHXXFW627JL3J4ZXOBY3DLRCQDPXA5CNFSM4C37F7H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRAT6Y#issuecomment-585239035>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHXXFUR3GVE3NNQTBGZ2ETRCQDPXANCNFSM4C37F7HQ>
.
|
|
@larsgk Just created a PR to Zephyr zephyrproject-rtos/zephyr#22775 |
After a week of trying to create a WebUSB compliant device that will auto load on Linux and Windows (both), I see that
I plan to publish my findings in a tutorial/blog for others but it would probably be a good idea with some more hands on examples for a few embedded systems (e.g. zephyr, mbed, etc.) - especially what to be careful with for different versions of windows, how to co-exist with other interfaces on the device, etc.
The text was updated successfully, but these errors were encountered: