The same applies to webcams, screensavers (with WebGL/WebGPU), audio processing plugins, and any other software that doesn't come bundled into the OS and doesn't have a UI as such.
The utility of WebASM for non-Web use cases is incredible.
[0] My scanner is by Epson, who have good Linux support, but the driver was built against an ancient GNU libc that's no longer distributed by Debian/Ubuntu. And it's amd64, so I can't use a RaspberryPi as a scan server.
[1] I prefer open source when available, but hardware vendors often have cultural or contractual blocks against open-sourcing their drivers.
I'm lost.
If WASM driver support were to be included in Windows and/or macOS, similar to how macOS and Linux share CUPS, then Linux support would be more widespread because the vendor's driver could be reused as-is.
I think the thought process behind "supporting one unified platform-independent bytecode would be easier than compiling a .so that works with all GNU libc versions" is straightforward and self-evident. Do you disagree?
Though I can't really understand why a printer driver needs such low level OS access so as to become a security risk as they sometimes are - aren't they basically a program that converts one image format to another, then flings that down a USB or network port?
The short answer to your question is: No.
Absolutely agreed, it really seems like a fascinating possibility.
What’s your take on how WASM drivers (meant to run in a web browser) could integrate at the OS level? For instance, if you wanted all installed desktop softwares to be able to print via the WASM printer driver?
wasm spec is fully defined and public, and we even already have source for browsers.
What prevents developing a wrapper or shim that runs any wasm as if it were any other native executable?
You might be legally prevented from redistributing the wasm, so maybe you can't bundle it right into a .deb or.rpm, but it's trivial in that case to just download on the fly if not exist and re-use after that. You may want it to check for updates all the time anyway.
As for browser API compatibility, I don't see much point to it since they're mostly designed with the assumption of a JS host. Ideally a WASM driver would export low-level functions to translate from (for example) PostScript to USB packets. Then the underlying native driver (Linux kernel module, Windows dll, etc) runs the WASM and handles all the IO, calling exported WASM functions as needed.
So I downloaded the source code of SANE, find the offending error message, commented it out and scanner worked without issue.
So I went the radeon kernel driver, and simply commented out that part. Never had a single glitch for the entire lifetime of the card, but oh god I did enjoy the silent fan-free operation.
And people wonder why I'm a staunch fanatic of free software.
- CUPS has existed for over 20 years
- Java has existed for over 25 years
However, I still not use CUPS or similar systems on Windows. And Java-based (or other VM-based) printer drivers have never been a thing AFAIK, on any platform.
There are however platform independent device support at a lower level, e.g. OpenFirmware and EFI. This is usually not leveraged post-boot.
http://www.sane-project.org/sane-backends.html
But HP is a special case, they provide their own backend (hpaio, open-source) for SANE that is not integrated into sane-wasm ATM.
http://www.sane-project.org/lists/sane-backends-external.htm...
If your device is on this list, it's NOT supported right now! But I do want to add hpaio soon, I also have access to an OfficeJet to test.
Go to the Drivers page on Brother's website, and for any recent macOS version, the answer is, "just use AirPrint".
Can you elaborate on your answer? Linux printer drivers seem to be entirely in userspace, so why do Windows drivers cause so much grief?
1. it doesn't really matter what I think
2. Compiling a .so that works with all glibc versions is almost certainly an order of magnitude easier than providing a unified wasm implementation that works on (at least) 3 platforms.
That definitely exists and is used on server-side - Wasmtime, Wasmer and others.
java isn't relevant, not because it couldn't be in theory, but because in reality, it's just not. Browsers never baked it in, it never became an open standard, etc, it's essentially no better than every other interpreted or compiled language. We could have a universal standard that's essentially bash, but we don't. We have bash, but it will never be a universal format the way wasm already is. Being baked into everyone's browser makes all the difference. When you want to publish a picture, tiff is a very versatile container and is better than most other formats, but the format you will actually use will be png or jpg etc, because even though many tiff viewers are available, they aren't built in to all browsers. It doesn't matter that tiff already existed and could do the same job. java is tiff.
