Chrome 61 Progresses With WebUSB API & More

[starshipeleven]

Ehem... Just what drivers for USB devices are you have an issue with breaking? This isn't the 90s this is absolutely not a problem anymore. Other buses have some issues particularly PCI/PCIe soundcards... but USB drivers are rock solid.

I'm talking of windows, the land where drivers tend to break in the next Windows release if the manufacturer isn't releasing an updated version (which rarely if ever happens after like 5 years).

Printer/scanner/wifi/cameras(not using UVC standard)/soundcards(not using usb sound standard)/TV tuner/whatever.

On Linux/BSD this is a nonissue for drivers included in kernel, stuff outside breaks even more often if there isn't a babysitter updating the code.

Also this would allow to use on Linux other devices that would only have a windows driver otherwise. Sure it's not awesomely efficient to have to waste 1GB with Chrome to use some USB device, but it's far better than having to use a Windows VM for it.

[starshipeleven]

You do realize this begs for a fappening sequel, because someone's photos on a USB stick left connected is going to end up all over the place. Fast.

You did read the papers right? This API requires support from the USB device itself, and I really doubt that usb sticks will add support en-masse for this when they work 100% fine everywhere with default mass storage drivers.

That said, I'm totally for a fappening sequel and I would support any technology that would allow this.

[starshipeleven]

just one word: IoT

Just one word: WTF?!

IoT is an embedded system running its own firmware that collects data somehow and sends it over a low-speed system. Drivers for its own stuff are in the firmware, not in the cloud.

At most you get kill-switched IoT like Pogoplugs, Seagate Dockstar and Cisco ON100 that are devices controlled by an external site (i.e. you log in somewhere and control them from there), that are now on sale for peanuts because the external service was shut down and the only way to use them is to open them, connect to serial UART port and flash a custom firmware (LEDE) or bootloader to boot Debian/Arch ARM.

But in neither case you have drivers for stuff on a remote server. It's only for authentication or some shit.

[karolherbst]

Just one word: WTF?!

IoT is an embedded system running its own firmware that collects data somehow and sends it over a low-speed system. Drivers for its own stuff are in the firmware, not in the cloud.

At most you get kill-switched IoT like Pogoplugs, Seagate Dockstar and Cisco ON100 that are devices controlled by an external site (i.e. you log in somewhere and control them from there), that are now on sale for peanuts because the external service was shut down and the only way to use them is to open them, connect to serial UART port and flash a custom firmware (LEDE) or bootloader to boot Debian/Arch ARM.

But in neither case you have drivers for stuff on a remote server. It's only for authentication or some shit.

the future is bright! I am not really serious about all this, but I am quite sure, that some of those hipster startups might thing it's a good idea to write drivers based on the webusb API and I wouldn't be surprised if this will become a thing.

Most of the IoT stuff is already completly insane and nobody in their right mind would ever do something like this. Pushing drivers onto the server is just the next step.

[starshipeleven]

the future is bright! I am not really serious about all this, but I am quite sure, that some of those hipster startups might thing it's a good idea to write drivers based on the webusb API and I wouldn't be surprised if this will become a thing.

And as I said this wouldn't even be that bad for reasons detailed above. Devices where it makes sense to have drivers in javascript are the oddball devices that are most likely to break between Windows versions and pretty much NEVAR have a Linux version.

All performance-critical stuff will need OS-side drivers, no way around that. Javascript will always lose vs a driver running with the OS.

Most of the IoT stuff is already completly insane and nobody in their right mind would ever do something like this. Pushing drivers onto the server is just the next step.

In case you missed it, the main reason I think it won't happen is because of network latency being totally ridiculous for a driver (even more so for mobile internet connections) so even if web clowns on drugs decide to try it it will flat out not work, period.

Unless we are talking of very very very very simple and dumb stuff like a keyboard or a "buttons over USB" thing where more than 300 ms of random latency are irrelevant (I'm ignoring gaming), anything newsworthy that requires the cloud to work will have to be running locally as javascript in browser and use a phone-home functionality, or work like chromecast that downloads the codecs or something from the internet.
So it's very likely that it can be hacked to work offline too, if the web app does not offer the possibility on its own.

Besides, it's not like current device drivers can't be made to work in a similar way (download necessary portions from a server).

[bug77]

You did read the papers right? This API requires support from the USB device itself, and I really doubt that usb sticks will add support en-masse for this when they work 100% fine everywhere with default mass storage drivers.

The same way laptop cameras turn a light on when recording, but during a filmed interview we see Mark Zuckerberg with a strip of paper over his camera?

That said, I'm totally for a fappening sequel and I would support any technology that would allow this.

Everybody would support this. Except for the ones actually involved

[Luke_Wolf]

I'm talking of windows, the land where drivers tend to break in the next Windows release if the manufacturer isn't releasing an updated version (which rarely if ever happens after like 5 years).

Printer/scanner/wifi/cameras(not using UVC standard)/soundcards(not using usb sound standard)/TV tuner/whatever.

On Linux/BSD this is a nonissue for drivers included in kernel, stuff outside breaks even more often if there isn't a babysitter updating the code.

Also this would allow to use on Linux other devices that would only have a windows driver otherwise. Sure it's not awesomely efficient to have to waste 1GB with Chrome to use some USB device, but it's far better than having to use a Windows VM for it.

Except... No they don't. Again this has not been an issue since the 90s. The USB Mass Storage, Audio, HID, etc standards made all the usual cases rock solid and for the ones that don't follow those standards Windows drivers don't really break between major versions because Windows has a stable hardware driver ABI. When it comes to USB devices, you could as a general rule be using 64-bit drivers for Vista on Windows 10 (and I have done this for a few devices for people), generally you can't go back to XP because the bitness will be wrong, but for USB drivers if the bitness was correct you could probably get away with it.

In fact the only USB devices I've seen or heard being lost to compatibility are Palm Pilots because the whole stack surrounding them was never updated for the 64-bit era. Older gamepads have lost compatibility with newer games but that has nothing to do with the USB drivers and everything to do with them only supporting DirectInput as opposed to XInput, and there's ways you can kind of get around that, but otherwise... I'm not aware of any other compatibility issues.

In fact by consequence of these standards USB Audio drivers are far superior to their PCIe counterparts.

[starshipeleven]

The same way laptop cameras turn a light on when recording, but during a filmed interview we see Mark Zuckerberg with a strip of paper over his camera?

Huh? You know right that mass storage device manufacturers don't develop drivers at all because they follow a standard?
Why should they be arsed to spend money in driver development when they never had to in the last decades and stuff always worked fine?

Everybody would support this. Except for the ones actually involved

I don't feel pity for them, all information that might damage you must be destroyed at once, not stored anywhere. Then you get kids that film themselves while committing crimes and uploading that on Facebook.... but I digress.

[starshipeleven]

Except... No they don't. Again this has not been an issue since the 90s. The USB Mass Storage, Audio, HID, etc standards made all the usual cases rock solid

except I was talking of printers, scanners, wifi, tv tuner dongles/cards, USB audio cards that needed their driver to do more than simple HD audio, SPI flashers and JTAG and other similar tools, usb to VGA cards, and whatever non-mainstream devices that made the a PC master race.

and for the ones that don't follow those standards Windows drivers don't really break between major versions because Windows has a stable hardware driver ABI.

Stable within the same release perhaps, between major releases nope. Or it may be stable enough but the driver is doing other stuff with system libraries and fails to work on newer ones.

When it comes to USB devices, you could as a general rule be using 64-bit drivers for Vista on Windows 10 (and I have done this for a few devices for people), generally you can't go back to XP because the bitness will be wrong, but for USB drivers if the bitness was correct you could probably get away with it.

Yeah, but you also could not, it's this gray area of "should work but might not" or "seems to work but crashes hard every now and then" that may come haunt you like the Spanish Inquisition.

[Luke_Wolf]

except I was talking of printers, scanners, wifi, tv tuner dongles/cards, USB audio cards that needed their driver to do more than simple HD audio,

All of which work just fine even with old drivers on modern windows. I know it does. I've done it for many a person that's come to me to fix or set up their computer. In fact it's never not worked. In fact with Windows 10 these devices are more plug and play than ever because half the time it'll download the driver for you.

SPI flashers and JTAG and other similar tools, usb to VGA cards, and whatever non-mainstream devices that made the a PC master race.

I can't personally speak to these, but given how utterly wrong you are about the former, and what I know of Windows Device Drivers I'm going to assume you're wrong about these too.

Stable within the same release perhaps, between major releases nope. Or it may be stable enough but the driver is doing other stuff with system libraries and fails to work on newer ones.

Yeah, but you also could not, it's this gray area of "should work but might not" or "seems to work but crashes hard every now and then" that may come haunt you like the Spanish Inquisition.

No... Not even close. How can you be this ignorant on the subject? With Windows unless there is a reason for them to have broken, then they're going to work. They have a stable hardware ABI and can do that as a result. The only big non-bitness related breakages in Windows Drivers were the redesigning of the Graphics and Audio subsystems that have caused the ABIs for those particular subsystems to break a few times. Otherwise if you find a driver for Vista or newer, it will work. I know, I've done it, it works. There's a reason most driver packages for the various windows versions that a manufacturer supports are really all the same file on the server, and claim OS support for a wide swath of windows releases, and it's not because there's a specific version for each version of windows all in the installer or some crap like that... no... It's because their ABI is stable and retains a high level of compatibility between releases.