Pretty sure you have my code in both projects. I contribute first and foremost to make printers and scanners to work reliably, but also keeping in mind the idea that I could at least try to apply legal actions for companies which violate the license rules one day, as a CUPS/SANE/printer/scanner drivers contributor.
Printer companies generally don't like that: https://xcancel.com/ValdikSS/status/1745898408693371125#m
Cool project though! Hope you can publish the source one day so we can all benefit from it in the future!
More broadly, it’s unusual for me not to make everything open, and I do feel bad/conflicted about it. But, unusually, I feel like I have identified a possible route to monetising this, and I think open-sourcing all of it risks making that harder.
Thankfully the Avision FB5100 states native Linux support (AFAIK, this is the only flatbed A3 scanner that does), so I'm certainly going to buy this one. I know implementing device support for companies that don't make any effort is hard and thankless, but then we need to divest/invest in the right companies and solutions.
After rereading both of your websites again, I should say you've nothing wrong! It's sleepy me who accused you for nothing, sorry.
Linux printing and scanning stack is held on 5 enthusiasts basically, and is quite buggy. Any contributions welcome.
If you want to further improve your project, make it small and fast, you can compile printer filters (most of which work on cups-raster data) with emscripten. This way you don't need to use CUPS, Linux, and x86 emulation. You'll need to write some shims for CUPS libppd functions which many filters use (some don't), and either parse PPD files or convert them into another representation.
Most filters (drivers) are quite simple pipes from stdin to stdout, sometimes they don't use cups functions at all, receiving all the data directly from raster header. Some filters, such as gutenprint, are more complex and use their own backends, but even in this case it's not a hard task: libusb has emscripten WebUSB backend.
> I must apologise that I haven’t so far open-sourced any part of this that I don’t have to.
With some blather about commercial opportunities. Which is a weird thing to say without linking to the bits that must be shared (under the terms of the various licenses).
It is a little much, but if it can be made to "Just Work" by booting a Linux kernel in the browser that it pretty cool and impressive. I'm still a little on the fence about my browser having USB support, but this could be handy for dusins of people.
Speaking of not just gluing stuff together with usb/ip could one make a virtual WebUSB host kernel module that could be used by the Linux kernel USB stack? They most likely would not want to do that because then all of the code would be GPL and would have to be shared with the public.
Interestingly, it was better executed than many of the downloadable native apps.
I wonder how much work would it be to port a given Linux USB driver to WASM alone?
