WebAssembly+WebUSB port of the SANE scanner library
1–10 of 27 posts
Re: WebAssembly+WebUSB port of the SANE scanner library
#2Many years ago friend gave me broken SCSI scanner. It always said "paper jammed". I thought I just short or remove the paper sensor but it wasn't simple kind of sensor, there were two and from the delay it decided whether the paper was jammed or not.
So I downloaded the source code of SANE, find the offending error message, commented it out and scanner worked without issue.
Re: WebAssembly+WebUSB port of the SANE scanner library
#3Many years ago friend gave me broken SCSI scanner. It always said "paper jammed". I thought I just short or remove the paper sensor but it wasn't simple kind of sensor, there were two and from the delay it decided whether the paper was jammed or not. So I downloaded the source code of SANE, find the offending error message, commented it out and scanner worked without issue.
I had one of these stupid AMD graphics cards (I think from the Evergreen generation) where the GPU/memory clocks would be locked in at the highest frequency whenever you had a second monitor plugged in. Apparently some sort of graphical glitches would be possible otherwise. In their infinite wisdom, AMD decided it was worth an extra 20W of baseline power consumption to avoid these glitches. (I am told they still do this as of today).
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.
Re: WebAssembly+WebUSB port of the SANE scanner library
#4IMO one of the biggest opportunities for WASM is printer and scanner drivers. These things have historically been distributed as native code, so the usability of the hardware on various OSes and architectures is spotty[0]. WASM is close enough to a native binary (fast, not source[1]) to be accepted by hardware vendors, but is inherently architecture-independent and in principle could be built to an OS-indendent API. Imagine sharing the exact same drivers for tens of thousands of devices across Windows, Mac, Linux, and every other OS that might exist in the future!
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.
Re: WebAssembly+WebUSB port of the SANE scanner library
#5Many years ago friend gave me broken SCSI scanner. It always said "paper jammed". I thought I just short or remove the paper sensor but it wasn't simple kind of sensor, there were two and from the delay it decided whether the paper was jammed or not. So I downloaded the source code of SANE, find the offending error message, commented it out and scanner worked without issue.
Re: WebAssembly+WebUSB port of the SANE scanner library
#6I just purchased a Chromebook, and it won't detect the scanner of my HP multifunction. Is this software my salvation?
Re: WebAssembly+WebUSB port of the SANE scanner library
#7IMO one of the biggest opportunities for WASM is printer and scanner drivers. These things have historically been distributed as native code, so the usability of the hardware on various OSes and architectures is spotty[0]. WASM is close enough to a native binary (fast, not source[1]) to be accepted by hardware vendors, but is inherently architecture-independent and in principle could be built to an OS-indendent API.…
I was just asking about this in a thread about a driver for an old webcam here yesterday! [0]
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?
Re: WebAssembly+WebUSB port of the SANE scanner library
#8I just purchased a Chromebook, and it won't detect the scanner of my HP multifunction. Is this software my salvation?
Chromebook is probably the perfect target for those kinds of ports. Definitely worth giving a try, hopefully SANE supports it.
Re: WebAssembly+WebUSB port of the SANE scanner library
#9IMO one of the biggest opportunities for WASM is printer and scanner drivers. These things have historically been distributed as native code, so the usability of the hardware on various OSes and architectures is spotty[0]. WASM is close enough to a native binary (fast, not source[1]) to be accepted by hardware vendors, but is inherently architecture-independent and in principle could be built to an OS-indendent API.…
I was just asking about this in a thread about a driver for an old webcam here yesterday! [0] 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? [0] https://news.ycombinator.com/item?id=3574565…
Browser ports can't integrate at OS level, they're intentionally separated today, but given that e.g. Node.js has WebUSB support (https://github.com/node-usb/node-usb), I guess you could make a layer that exposes such Wasm drivers as native to the OS. Could be a fun experiment.
Re: WebAssembly+WebUSB port of the SANE scanner library
#10IMO one of the biggest opportunities for WASM is printer and scanner drivers. These things have historically been distributed as native code, so the usability of the hardware on various OSes and architectures is spotty[0]. WASM is close enough to a native binary (fast, not source[1]) to be accepted by hardware vendors, but is inherently architecture-independent and in principle could be built to an OS-indendent API.…
I was just asking about this in a thread about a driver for an old webcam here yesterday! [0] 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? [0] https://news.ycombinator.com/item?id=3574565…
Application software would still go through the OS native printing APIs. Office or Chrome don't directly interact with the vendor's driver.
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.