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.

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

Falling back to WebUSB user-space drivers on MacOS #204

Open
gniezen opened this issue Jun 6, 2024 · 3 comments
Open

Falling back to WebUSB user-space drivers on MacOS #204

gniezen opened this issue Jun 6, 2024 · 3 comments

Comments

@gniezen
Copy link

gniezen commented Jun 6, 2024

On MacOS it is becoming more and more difficult to install kernel extensions, and their successor since Catalina, driver extensions. It can also be challenging to get a DriverKit entitlement in order to write a driver extension. Apple includes built-in kernel/driver extensions for a number of chipsets, but not all, and these also don't work if the device has a custom USB PID/VID.

Luckily, if there is no existing USB serial port driver installed, MacOS will load the default USB driver, which can be accessed over WebUSB. I have written a bunch of JS user-space drivers for FTDI, Texas Instruments, Silicon Labs and Prolific chipsets, and these work well as a fallback mechanism.

However, It does lead to a confusing user experience, where we first have to display the Web Serial permission prompt in case there is a USB driver already installed, and then display the WebUSB permission prompt when the user presses Cancel (as the Web Serial API doesn't find any devices) so that we can then connect using WebUSB instead.

Could there be away to make Web Serial a little bit more aware of WebUSB, for example by providing a new method that would automatically fall back to navigator.usb.requestDevice when navigator.serial.requestPort comes up empty?

@reillyeon
Copy link
Collaborator

There's an issue on the WebUSB side tracking this: WICG/webusb#186

@gniezen
Copy link
Author

gniezen commented Jun 7, 2024

Ah, that's great, thanks @reillyeon ! I should probably have checked there first, but at least now we have issues on both repos tracking this. How can I help move this forward?

@reillyeon
Copy link
Collaborator

The challenge is mainly on the implementation side. There's platform-specific work necessary to make sure we're modeling the device relationships correctly between the platform USB, serial and HID APIs. It's something that's on our team's roadmap but I can't make any promises on when we'll be able to deliver it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants