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.
Conversation
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.
2
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.
The confusing part is that many people already have the driver or end up with it after plugging in the device. Others have to manually install it either via developer.android.com/studio/run/oem or as an optional update in Windows Update which seem hard for end users to find and install.
1
1
Definitely. WebUSB is much easier when you get to define the vid/pid on the hardware side.
really cool that Graphene is tackling this with webUSB, btw.
Interesting problem. Haven't spent any time with fastboot internals. Maybe there's a secondary interface the driver hits?