Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Better reference documentation on descriptors #75

Closed
larsgk opened this issue Jan 10, 2017 · 91 comments
Closed

Better reference documentation on descriptors #75

larsgk opened this issue Jan 10, 2017 · 91 comments

Comments

@larsgk
Copy link

larsgk commented Jan 10, 2017

After a week of trying to create a WebUSB compliant device that will auto load on Linux and Windows (both), I see that

  1. there are not that many OSS WebUSB (firmware) implementations out there (apart from the arduino one)
  2. the arduino one is very specific to one device and is probably relying on udev rules (linux) and winusb drivers (windows) somehow already present
  3. the documentation from Microsoft on the MS 2.0 descriptors and how exactly they should be laid down for WebUSB to be picked up in a composite device is... sorta non existant
  4. No collected generic "how to create these typical WebUSB devices by example" documentation seem to exist

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.
@larsgk
Copy link
Author

larsgk commented Jan 10, 2017

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

@sowbug
Copy link

sowbug commented Jan 10, 2017 via email

@larsgk
Copy link
Author

larsgk commented Jan 10, 2017

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)

@devanlai
Copy link

@larsgk: Can you post what Chrome records under chrome://device-log/ ?
I've been troubleshooting some non-mbed/Arduino composite WebUSB firmware on Windows that fails on the control transfer when it tries retrieve the BOS,

@larsgk
Copy link
Author

larsgk commented Jan 10, 2017

@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

@devanlai
Copy link

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.

@larsgk
Copy link
Author

larsgk commented Jan 10, 2017 via email

@devanlai
Copy link

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.
On Windows 10, after auto-installing WinUSB using the Microsoft OS 2.0 descriptors, it's the same situation, except Chrome reads all of the USB strings as blanks, so it shows up in the device picker as an Unknown device from .

In both cases, the actual WebUSB control transfers work fine.

@larsgk
Copy link
Author

larsgk commented Jan 11, 2017

@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

@larsgk
Copy link
Author

larsgk commented Jan 11, 2017

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 :)

@larsgk
Copy link
Author

larsgk commented Jan 11, 2017

I am beginning to suspect there is a bug (or 2) in chrome - related to WebUSB.

  1. it seems odd that the official Windows 10 WinUSB driver seems to load correctly when the correct (version 1 or 2) MS OS descriptors are in place - but Chrome only lists it once a much older (probably libusb related) driver is forced on the interface (see above)
  2. even with the working driver forced on, unplugging/replugging the device gives unreliable detection on the chrome side (approx every other time.. but no consistent pattern) - indicating there might be some race condition or other related to when Chrome reads the descriptors...

thoughts?

@devanlai
Copy link

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

@larsgk
Copy link
Author

larsgk commented Jan 11, 2017 via email

@reillyeon
Copy link
Collaborator

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.

@larsgk
Copy link
Author

larsgk commented Jan 12, 2017

@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?

@larsgk
Copy link
Author

larsgk commented Jan 14, 2017

@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

@larsgk
Copy link
Author

larsgk commented Jan 14, 2017

@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

@devanlai
Copy link

The license looks fine - I just went with Apache because it's what mbed uses.
IIRC, any valid GUID should be fine. It might need to be at least as unique as your VID/PID pair, but I'm still not very familiar with USB access on Windows.

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.

@larsgk
Copy link
Author

larsgk commented Jan 14, 2017

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 ;))

@larsgk
Copy link
Author

larsgk commented Jan 14, 2017

Probably related: https://bugs.chromium.org/p/chromium/issues/detail?id=637404

@pbatard
Copy link

pbatard commented Jan 16, 2017 •
edited
Loading

the documentation from Microsoft on the MS 2.0 descriptors and how exactly they should be laid down for WebUSB to be picked up in a composite device is... sorta non existant

Does this help? WCID is just another (more generic) name for MS descriptor based driver installation. You're talking about composite devices though...

@larsgk
Copy link
Author

larsgk commented Jan 16, 2017

@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.

@pbatard
Copy link

pbatard commented Jan 16, 2017

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 .inf file. While I don't doubt that you are experiencing an issue, I think maybe some more digging is needed with regards to its actual cause...

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):

D:\libusb\Win32\Debug\examples>xusb 04D8:FA2F
Using libusb v1.0.21.11121

Opening device 04D8:FA2F...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 3
           VID:PID: 04D8:FA2F
         bcdDevice: 0001
   iMan:iProd:iSer: 1:2:3
          nb confs: 1

Reading BOS descriptor: no descriptor

Reading first configuration descriptor:
             nb interfaces: 1
              interface[0]: id = 5
interface[0].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 00.00.00
       endpoint[0].address: 01
           max packet size: 0020
          polling interval: 00
       endpoint[1].address: 81
           max packet size: 0020
          polling interval: 00

Claiming interface 0...

Reading string descriptors:
   String (0x01): "Travis Robinson"
   String (0x02): "Benchmark Device"
   String (0x03): "LUSBW1"
   String (0xEE): "MSFT100 "

Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):

  00000000  28 00 00 00 00 01 04 00 01 00 00 00 00 00 00 00  (...............
  00000010  00 01 57 49 4e 55 53 42 00 00 00 00 00 00 00 00  ..WINUSB........
  00000020  00 00 00 00 00 00 00 00                          ........

Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):

  00000000  8e 00 00 00 00 01 05 00 01 00 84 00 00 00 01 00  ................
  00000010  00 00 28 00 44 00 65 00 76 00 69 00 63 00 65 00  ..(.D.e.v.i.c.e.
  00000020  49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00  I.n.t.e.r.f.a.c.
  00000030  65 00 47 00 55 00 49 00 44 00 00 00 4e 00 00 00  e.G.U.I.D...N...
  00000040  7b 00 46 00 37 00 30 00 32 00 34 00 32 00 43 00  {.F.7.0.2.4.2.C.
  00000050  37 00 2d 00 46 00 42 00 32 00 35 00 2d 00 34 00  7.-.F.B.2.5.-.4.
  00000060  34 00 33 00 42 00 2d 00 39 00 45 00 37 00 45 00  4.3.B.-.9.E.7.E.
  00000070  2d 00 41 00 34 00 32 00 36 00 30 00 46 00 33 00  -.A.4.2.6.0.F.3.
  00000080  37 00 33 00 39 00 38 00 32 00 7d 00 00 00        7.3.9.8.2.}...

Releasing interface 0...
Closing device...

I also confirmed afterwards that Zadig did report the driver version to be WINUSB (v10.0.14393.0).

@larsgk
Copy link
Author

larsgk commented Jan 16, 2017

@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.

@pbatard
Copy link

pbatard commented Jan 16, 2017 •
edited
Loading

it's clear that there are some issues with libusb + the vanilla WinUSB driver

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.

My current implementation is this

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...

but only after applying the older driver from Zadig

Which should basically equate to applying an inf file. The winusb.sys being used will still be the one that came with Windows 10.

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.

@larsgk
Copy link
Author

larsgk commented Jan 16, 2017

but only after applying the older driver from Zadig

Which should basically equate to applying an inf file. The winusb.sys being used will still be the one that came with Windows 10.

Mine reports as being 6.xx after applying the driver.

In any case - it seems like a bug (on the libusb/chrome side) when

  1. windows seems to (finally) install CDC & WinUSB drivers correctly (all info inside the device manager looks fine) out of the box with a fresh/unknown VID/PID (to provoke proper first time use) and
  2. chrome only finds the device after applying the driver that seems to ship with Zadig on the interface using WinUSB.

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 .

@larsgk
Copy link
Author

larsgk commented Jan 16, 2017

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...

It's on the specific interface - the same as happens automatically with the device on first time, where:

  1. the composite part gets the composite driver (usbccgp),
  2. the CDC part gets the serial driver (usbser) and
  3. the WebUSB part gets the generic driver (winusb) - it even gets the name correctly, etc... seems to work just fine (just not libusb and chrome)

@pbatard
Copy link

pbatard commented Jan 16, 2017

Mine reports as being 6.xx after applying the driver.

That's because Zadig gets it from the .inf and not the actual binary, and Zadig populates the version from the inf from the file it embeds, even if these binaries aren't really going to be used during install. If you look for an actual winusb.sys or winusb.dll with versions 6.x, you won't find one. And C:\Windows\INF\setupapi.dev.log will also tell you the same:

     inf:                               {Configure Driver: Benchmark Device}
     inf:                                    Section Name = USB_Install
     inf:                                    {Add Service: WinUSB}
     inf:                                         Start Type    = 3
     inf:                                         Service Type  = 1
     inf:                                         Error Control = 1
     inf:                                         Image Path    = \SystemRoot\System32\drivers\WinUSB.sys
     inf:                                         Display Name  = WinUSB - Kernel Driver 03/30/2015 6.1.7600.16385
     inf:                                         Updated service 'WinUSB'.
     inf:                                    {Add Service: exit(0x00000000)}
     inf:                                    Hardware Id  = USB\VID_04D8&PID_FA2F
     inf:                                    {Configure Driver Configuration: USB_Install}
     inf:                                         Service Name  = WinUSB
     inf:                                         Included INFs = winusb.inf
     inf:                                         Config Flags  = 0x00000000
     inf:                                    {Configure Driver Configuration: exit(0x00000000)}
     inf:                               {Configure Driver: exit(0x00000000)}
     flq:                               Hardlinking 'C:\Windows\System32\DriverStore\FileRepository\winusb.inf_amd64_29178b272f47d69b\winusb.sys' to 'C:\Windows\System32\drivers\winusb.sys'.
     cpy:                               Existing file 'C:\Windows\System32\drivers\winusb.sys' remains unchanged.
     flq:                               Copying 'C:\Windows\System32\DriverStore\FileRepository\benchmark_device.inf_amd64_5bc2acbf32254514\amd64\WinUSBCoInstaller2.dll' to 'C:\Windows\System32\WinUSBCoInstaller2.dll'.
     cpy:                               Existing file 'C:\Windows\System32\WinUSBCoInstaller2.dll' remains unchanged.
     flq:                               Copying 'C:\Windows\System32\DriverStore\FileRepository\benchmark_device.inf_amd64_5bc2acbf32254514\amd64\WdfCoInstaller01011.dll' to 'C:\Windows\System32\WdfCoInstaller01011.dll'.
     cpy:                               Existing file 'C:\Windows\System32\WdfCoInstaller01011.dll' remains unchanged.

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 .inf, but I never managed to get around to doing that.

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.

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.

It's on the specific interface

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 .inf, but not WCID) to be able to access the composite interface...

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.

@larsgk
Copy link
Author

larsgk commented Jan 16, 2017 •
edited
Loading

@pbatard thanks for all the input.

/rant
Windows is a pain (why don't they look at the standard descriptors and deduct what to load like the other OSes?)
/rant end

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 ;)

@pbatard
Copy link

pbatard commented Jan 16, 2017 •
edited
Loading

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 DeviceInterfaceGUID (singular) instead of DeviceInterfaceGUIDs (plural), since you're only defining a single GUID for that interface anyway. Or maybe you need to define 2 GUIDs there, since you have two IFs...

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...

@devanlai
Copy link

@mon:
As a workaround for the composite interface issue, try moving the bulk WebUSB interface descriptor before the HID interface. I've found that putting the WebUSB interface first helped in some cases - maybe libusb is getting lost in parsing the descriptors.

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.

@mon
Copy link

mon commented Jan 31, 2017 •
edited
Loading

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!

@oostap1
Copy link

oostap1 commented Jan 31, 2017 •
edited
Loading

@mon you scared me.
OK. Modified arduino project to add Keyboard as well there. As @devanlai proposed inserted HID after WebUSB and now see both in Device Manager.

There steps to do that with arduino:

  1. Add #include <Keyboard.h>
  2. Find Keyboard.cpp in arduino tree and comment out static initialization on bottom (to control place, where HID interface is inserted):
    //Keyboard_ Keyboard;
  3. Add static initialization after WebUSB, like that:
    WebUSB WebUSBSerial(URLS, 2, 1, ALLOWED_ORIGINS, 2);
    Keyboard_ Keyboard;

I do not have any buttons connected to arduino to verify HID but WebUSB works OK.

@mcuee
Copy link

mcuee commented Feb 1, 2017

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.
libusb/libusb#85

@Gamadril
Copy link

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?

@larsgk
Copy link
Author

larsgk commented Jul 16, 2017

@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.

@Gamadril
Copy link

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...

@Tronil
Copy link

Tronil commented Aug 1, 2017

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?...

@larsgk
Copy link
Author

larsgk commented Aug 1, 2017

Great find @Tronil

^ @reillyeon

@Gamadril
Copy link

Gamadril commented Aug 7, 2017

I found in Chrome for Windows the flag #new-usb-backend

Enables the new experimental USB backend for Windows. #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().

@larsgk
Copy link
Author

larsgk commented Aug 7, 2017

@Gamadril it seems the new backend will replace libusb - but I think @reillyeon mentioned it doesn't support composite devices yet

@reillyeon
Copy link
Collaborator

@Gamadril @larsgk The new backend only supports device enumeration. I'm glad that it is listing the device correctly (including the device name) as that is what I landed the code early to test however you won't find it useful beyond that because the open() function is entirely stubbed out.

@Gamadril
Copy link

Gamadril commented Aug 8, 2017

@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...

@reillyeon
Copy link
Collaborator

@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.

@larsgk
Copy link
Author

larsgk commented Aug 8, 2017

@Gamadril if you need help getting a solution working ASAP, feel free to ping me on twitter ( denladeside )

@Gamadril
Copy link

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.
However windows is still the exception... Chrome for Windows still has a restriction regarding WinUSB drivers - that's a pain, especially now where you don't need any firmware changes at all on Mac and Linux. New Windows USB backend in Chrome seems to solve that problem, but is still not working. Is there any progress or maybe a roadmap for the new backend? I have about 10 devices I plan to "connect to the web", but I would prefer waiting for the new backend instead of modifying each bootloader to make it "WinUSB" compatible for windows.

@karelbilek
Copy link

Hm. So it seems chrome on windows is still using the libusb backend with all the bugs mentioned here, right? :(

@larsgk
Copy link
Author

larsgk commented Dec 5, 2017

@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,

@karelbilek karelbilek mentioned this issue Dec 7, 2017
Closed
karelbilek added a commit to trezor/trezor-mcu that referenced this issue Dec 9, 2017
@karelbilek
Adding GUIDs, clean up winUSB
0c8acaf 
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
@karelbilek
Copy link

karelbilek commented Dec 9, 2017 •
edited
Loading

@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

@larsgk
Copy link
Author

larsgk commented Dec 9, 2017 via email

@karelbilek
Copy link

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

@reillyeon
Copy link
Collaborator

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.

@karelbilek
Copy link

karelbilek commented Mar 16, 2019 •
edited
Loading

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

@karelbilek
Copy link

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).

@xiongyihui
Copy link

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

@larsgk
Copy link
Author

larsgk commented Feb 12, 2020 via email

@xiongyihui
Copy link

@larsgk Just created a PR to Zephyr zephyrproject-rtos/zephyr#22775

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests