You still need a working fastboot driver with the WebUSB installer.
macOS and Linux have it built-in.
Some Windows users get it automatically. Others need to manually install it as an optional update in Windows Update. We'll be adding it to the guides for both install methods.
Conversation
Replying to
is that a driver for a different vendorid/productid? Having a driver installed keeps webUSB from being able to claim a device.
1
WebUSB uses the regular driver for the device. That means you need the usual udev rules for Linux distributions not permitting users with physical access to access all USB devices. Windows users need to install the fastboot driver from Windows Update or from Google. Either works.
1
WebUSB can talk directly to a device if you know the vendorId and productId. If you have a driver installed on your OS, the device is already claimed.
You shouldn't need to install a driver.
2
This is one of the reasons webSerial is such a nice thing. For example, things like FTDI/CH340 preinstalled stop you from interacting via webUSB
1
That's not how it works with fastboot. If you don't have the fastboot driver on Windows, it doesn't work via WebUSB. It's the opposite of needing to avoid the driver for this to work. It sounds like you're talking about a different kind of device where certain drivers break it.
1
It sounds like what you're saying is with the kind of device you've tested, the default driver works, and certain non-default drivers break it. Linux and macOS already have the fastboot driver. Windows users often get it automatically. Doesn't break WebUSB but rather is required.
1
is that driver claiming the same vID/pID as webUSB is filtering with requestDevice()?
Driver is sometimes an overloaded term.
1
If you don't have developer.android.com/studio/run/oem or the variant of it from Windows Update on Windows, you can't use WebUSB for fastboot or adb. That's all I know. On Linux and macOS, the generic kernel driver for USB devices works fine. Are you talking about Windows or another OS?
1
Any os with it installed is supposed to fail to claim the device if another driver already has claimed it.
"The claimInterface() function will fail if multiple execution contexts attempt to claim an interface." from: wicg.github.io/webusb/#abusin
2
It will fail if you're already running fastboot elsewhere. I'm not saying that you need to install fastboot and run it. That's the grapheneos.org/install/cli guide. I'm talking about the driver. Regardless of how it's documented in the web standard, the implementation requires this.
No driver for the device and WebUSB won't be able to use it. The driver doesn't claim the device. It makes it available for usage by programs. If you're already using fastboot, then sure, WebUSB can't use it. If you don't have the driver on Windows, you can't use it either way.
1
1
Also, the WebUSB API for fastboot on Windows is different than on Linux and macOS. On Windows, you can't reset the device. On Linux, if you don't reset the device, it ends up being broken in many cases. Windows driver for the device doesn't support reset but it's harmless to try.
1
ahhh, it must not claim it when fastboot isn't running then.
You 100% certain you can't implement the loader completely in webUSB without the driver?
1
I think this is how WebUSB has to work on Windows. macOS and Linux have their generic USB drivers. Windows doesn't seem to support it. The way fastboot works on Windows either via the CLI tool or via WebUSB is fundamentally a different approach. Doesn't work without that driver.
2
1
Show replies