好嗎?我是ㄧ名新手,應該甚樣處理這件事（工作）我是沒有經驗的"希望"你們能夠指導我"謝謝你們。

I guess this is related to the problems we see here: https://github.com/WICG/webusb/issues/75#issuecomment-272592135

Would it be possible to use the Windows APIs for communication?
Something in the area of https://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx

Some more info:

For Linux (probably Mac as well), both WebUSB notification and communication works correctly (after allowing user access to the device in udev rules).

For Windows, it seems that libusb only works with a non-standard WinUsb driver (one of several issues... https://github.com/libusb/libusb/issues/255 ).

I've managed to generate windows specific descriptors that - in the end - result in a proper driver loading for both the CDC and the WebUSB part here:   https://github.com/larsgk/empirikit-controller/blob/master/WebUSBCDC.cpp  (The extended properties part seems not to be needed - but not 100% sure - so leaving it there for now).

When the hardware is inserted and the VID/PID is unknown to the system, windows 10 correctly loads it's CDC driver for the CDC part and the WinUSB driver (version 10) for the WebUSB part (no red flags).  However, it seems that chrome never finds the device until I manually force an older WinUSB driver (version 6 - probably modified also) on the interface.

The reason why the Arduino 101 most probably worked fine during development is that the Arduino 101 throws in a custom driver/WCID (or combo) for the device.

As far as I can see, one of two things must happen:

1. change the chrome implementation to use proper vanilla WinUSB APIs (not go through libusb for windows) or
2. fix libusb so no custom driver is needed

It might make sense to try to make a small test app using the windows WinUSB APIs (not libusb) to see if they work where libusb doesn't (against a device with autoloaded WinUSB driver).  I can try to see if i find the time today.

I tried the windows approach - it's very complex...

However, https://github.com/fpoussin/QtUsb makes it much easier to at least get notifications on devices added/removed, etc.  I'm currently using it to see if I can get the right details through - *maybe* GUIDs are needed for windows to be able to connect to them.  I am wondering if the way forward is to e.g. apply a WebUSB guid (like the classes here or similar: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820(v=vs.85).aspx ) on the WebUSB interfaces. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68032f0f92a27f22be31893b6438b9229302e944

commit 68032f0f92a27f22be31893b6438b9229302e944
Author: Reilly Grant <reillyg@chromium.org>
Date: Wed Dec 20 03:41:53 2017

Start supporting some transfers in the new Windows USB backend

This patch starts adding support for opening USB devices and issuing
requests to them when using the new Windows USB backend. Only non-
composite devices are supported currently as enumerating the device
paths for composite devices is more complex.

This has been tested with a WebLight which is a non-composite device
that only requires control transfers.

Bug: 637404
Change-Id: Ib792896435106bd03b3d5743608be44a22d4b153
Reviewed-on: https://chromium-review.googlesource.com/834887
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525253}
[modify] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/BUILD.gn
[add] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/scoped_winusb_handle.cc
[add] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/scoped_winusb_handle.h
[modify] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/usb_device_handle_win.cc
[modify] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/usb_device_handle_win.h
[modify] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/usb_device_win.cc
[modify] https://crrev.com/68032f0f92a27f22be31893b6438b9229302e944/device/usb/usb_device_win.h

Issue 898738 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/20ed0889b6a64c8edd1364ffda59d98ff561d098

commit 20ed0889b6a64c8edd1364ffda59d98ff561d098
Author: Reilly Grant <reillyg@chromium.org>
Date: Fri Nov 02 03:02:08 2018

Fix bulk/interrupt transfers in the new Windows USB backend

This change fixes a number of issues with sending bulk and interrupt
transfers to a USB device using the new Windows backend.

* Posting completion callbacks to the proper thread (a requirement for
  DevTools) has been fixed.
* Overlapped I/O results are now read using the correct method
  (WinUsb_GetOverlappedResult) and from the correct handle.
* Aborting transfers on handle close no longer results in a double-free.

Bug: 637404
Change-Id: I4fdb254e4ea6e9cbf7d764f588c94d698d61cb02
Reviewed-on: https://chromium-review.googlesource.com/c/1313828
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604827}
[modify] https://crrev.com/20ed0889b6a64c8edd1364ffda59d98ff561d098/device/usb/usb_device_handle_win.cc
[modify] https://crrev.com/20ed0889b6a64c8edd1364ffda59d98ff561d098/device/usb/usb_device_handle_win.h

Hello folks!

Do we have an update on Chrome for Windows support to WebUSB?

I have it perfectly working on Chrome for Mac OSX, but on Windows I'm struggling as whenever I call `device.open()` I have an "Access denied"...

I also tried the latest "Canary" build and still the same problem...

Can someone give me an estimation when this issue is supposed to be fixed?

Thank you! I appreciate any info!

As you can see from the patch above the work is still in progress. I can't give any specific timeline.

If your device is *not* composite then I would appreciate early testing of this new code by setting chrome://flags/#new-usb-backend to "enabled".

However, an "Access denied" error that only shows up on Windows likely indicates that the WinUSB driver is not loaded for the device. Before continuing open up the Device Manager, find your device and check which drivers are loaded. If winusb.sys is not in the list then the OS will not let Chrome open it.

Hi, 

As Reilly mentioned, did you check the windows device manager to see there are no warning signs (yellow triangles) on the device as you plug it in and that it actually gets added? Windows is a bit special - here is a link to some code that I need to revisit for a cleanup but might give you some hints: https://github.com/empirikit/empirikit-controller/blob/master/WebUSBCDC.cpp and https://os.mbed.com/users/larsgk/code/USBDevice_WebUSB/file/1d8a6665d607/WebUSBDevice/WebUSBDevice.cpp/

Ahhh okey, now everything makes sense...

My device is detected as a Serial port on Windows. The driver loaded wasn't winusb.sys so even if I enable the new backend, I still get the "Access denied".

Luck for me, I found https://zadig.akeo.ie/ which basically replace the driver loaded for a particular device so now it is not appearing as a regular COM Port, it is now detected as a "real" USB Serial Device without a COM port attached to it, and now chrome is able to connect to it just fine even without enabling the new backend flag.

Yeah, that is a hack, but I'm very happy that this workaround will work for me now and unblock us while you guys are able to work on the real fix.

Thank you very much for the support and please let me know once you have some news about this issues and I'll be glad to help testing! 

Thanks!

Just to clarify, the solution you found is not a temporary workaround, it is the only way you can make this device work with the WebUSB API. This is a limitation imposed by the architecture of the Windows operating system and not something Chrome can fix. The Zadig tool requires administrator-level permissions and makes a permanent change to the system configuration in order to replace the driver. That is not something that the browser should do.

Looking forward we are working on implementing the Serial API[1] which will allow you to connect to a device through the Windows COM port driver.

This conversation has gotten off-topic for this issue. If you run into further problems please file another isue.

[1]: https://wicg.github.io/serial/