I would be interested in one.

Would it be possible to hook a USB hub up to the USB port and have this device be able to host multiple printers?

cyclone3d wrote on 2026-07-19, 15:43:

Would it be possible to hook a USB hub up to the USB port and have this device be able to host multiple printers?

Yes, it works that way. The only limitation is that you can't do that with Canon CAPT-based printers (at least without manual tinkering). All the other printers could be connected over USB hub.
The device is used by printer technicians who refill cartridges, they have about a dozen of printers connected to a single print server.

Excellent! Definitely interested then. That should be a big selling point.

Hi Tracer-5!

I implemented a significant subset of that functionality (for a single printer scanner model with official current x86-64 Linux support, admittedly ) for my own printing and scanning needs in a small VM that runs on my NAS machine (Debian x86-64) [1] a little while back [1]. Had I known about your polished, turnkey solution at the time, I might not have bothered DIY-ing it.

In fact, I have been considering DIY-ing a similar setup for my mom using either an older Raspberry Pi or an old Chromebook or Chromebox. However, if your solution is available, works seamlessly and is easy to set up, I think it would be worthwhile even for me to buy it instead of DIY-ing it. Time is one of my more significant constraints, these days.

Depending on how full featured the scanner support is, your solution might be a viable alternative to SilverFast, for at least some use cases.

In the context of today's memory prices, up to 60 $ (presumably USD), is not unreasonable, far from it. That being said, I do wonder if it might possibly be worthwhile for you to offer multiple hardware tiers, depending on the needs of a given use case. For example, if a given printer/scanner does have ARM compatible binaries, maybe a lower performance/spec platform could suffice. Similarly, if an end user does not need WI-FI, an Ethernet-only option might be lest costly. Obviously, this would all need to be balanced with the potentially higher development, maintenance and support efforts and costs.

[1]
Re: Moments in computing history when you felt that the future had arrived
Re: What retro activity did you get up to today?

darry wrote on Yesterday, 00:27:

Had I known about your polished, turnkey solution at the time, I might not have bothered DIY-ing it.

Hey, yes, that's my main reason for this device to exist. If I could buy something like this on the market, I would.

darry wrote on Yesterday, 00:27:

Depending on how full featured the scanner support is, your solution might be a viable alternative to SilverFast, for at least some use cases.

Scanning is based on SANE + AirSane, probably only basic support for dedicated scanner if that's what you're thinking.

darry wrote on Yesterday, 00:27:

That being said, I do wonder if it might possibly be worthwhile for you to offer multiple hardware tiers, depending on the needs of a given use case. For example, if a given printer/scanner does have ARM compatible binaries

Emulation is not that low-performance for everything except Canon UFR-II. This one has only x86, x86_64 and ARM64 builds, and more or less the only reason to choose ARM64 CPU instead of a simpler ARMv7.
I though about tiers, it's possible to make a cheaper device with slow UFR-II driver (and everything other relatively fast), but the main issue with tiers is that you get different Wi-Fi module as well.
Wi-Fi modules are one worse than the other, all buggy and requires testing, validation and bug fixing. I'm 100% sure Wi-Fi modules are the core reason that Wi-Fi printers are deem unreliable, because all of them have issues with Multicast in one way or another.

https://printserver.ink/blog/blame-wifi-drive … scovery-issues/

darry wrote on Yesterday, 00:27:

Ethernet-only option might be lest costly

Average user wants Wi-Fi connectivity. If there's a tier, all of them will have Wi-Fi, and Ethernet is made optional (USB module). I used to have such setup with my first Orange Pi 3G-IoT board, where I enabled all Realtek-based USB-Ethernet adapters as a connectivity option.

Anyway, here's the website: https://printserver.ink/
And a changelog: https://printserver.ink/docs-en/firmware/
The majority of the bugs in changelog are triaged and fixed by me.

Had I known there was a pre-built option, yes I would have preferred to pay $60 for it rather than building my own.

My printer is Canon CAPT which as you know presents unique challenges. I wanted to go arm but couldn't face the prospect of getting the x86 part of the driver working with box86. So I caved and bought a low-power x86 thin client, but found the gpu would only work with 64bit linux installed for some unknown reason. So then I had to grapple with the 64bit driver, which secretly has a 32bit-only component requiring multiarch setup. Add to that it only had 2gb emmc so I had to juggle the install/upgrade process so as not to run out of disk.

Eventually got it all working, even got a light desktop installed so I can vnc into it and use the canon desktop widget. But it was a major hassle and I wouldn't recommend self-build of this type of appliance, even to experienced tinkerers.
If I found I was in need of another I would gladly pay for pre-built.
I had no idea that my printer was from a 'golden era', or even that there was a golden era.
By the way, thanks for you work on CUPS.

This just sounds like CUPS running on a pi-Zero-W?

Spark wrote on Yesterday, 17:15:

My printer is Canon CAPT which as you know presents unique challenges. I wanted to go arm but couldn't face the prospect of getting the x86 part of the driver working with box86.

If it's monochrome, I've almost finished the work on the driver. It works fine, but from architectural standpoint it's a human+ai slop which I'm planning to rewrite
https://github.com/valdikss/captdriver

If it's the older LBP-810 or 1120, darkvision77 with a little help from my side reverse-engineered and created a proper driver from scratch last year
https://github.com/darkvision77/captppd

Spark wrote on Yesterday, 17:15:

Eventually got it all working, even got a light desktop installed so I can vnc into it and use the canon desktop widget.

If you need it because there's a bug in Canon's driver which requires to press the button to continue printing after paper jam, here's a small hack I made, in the attachment.

Spark wrote on Yesterday, 17:15:

By the way, thanks for you work on CUPS.

You are welcome, that was a long journey of pretty annoying bugs.

wierd_w wrote on Yesterday, 17:55:

This just sounds like CUPS running on a pi-Zero-W?

It is, more or less, with glorified web interface and with dozens of package patches, on a verified hardware.

My main goal is to improve all underlying stacks and printer drivers so everybody could benefit from it. Unfortunately, it takes years until all the distros update everything, so you can get all my patches which went into CUPS, cups-filters, SANE, and printer drivers only in about ≈2 years at least.
The bugs could be literally in every stack. Many Wi-Fi chipsets are buggy (see above), Raspberry Pi 4's VIA USB host controller is buggy and loses packets (and it haven't been fixed as far as I could see), kernel's USB1.1 support is a big buggy… I can go on and on and on.

I thought that would be a 3-month project at most in the beginning. Turned out 3 years.

I mean, CUPS already HAS a web interface. It has had one for a very long time?

Crappy SoC drivers are a whole other ball of wax though, I will give you that. Vendors just LOVE their SECRET SAUCE bullshit.

All this can be easily done on an OPENWRT-compatible router with USB ports without additional hardware.

wierd_w wrote on Yesterday, 21:44:

I mean, CUPS already HAS a web interface. It has had one for a very long time?

Web interface with Wi-Fi configuration, CUPS tunables, third-party soft configuration. Everything it makes to avoid accessing the device over SSH and editing the configuration files manually.

shevalier wrote on Today, 05:07:

All this can be easily done on an OPENWRT-compatible router with USB ports without additional hardware.

OpenWRT does not have CUPS or even IPP-USB in the repositories. It only has p910nd, which is a port-forwarding daemon like the print servers from the 90s. It just wrap printer port over TCP. Does not provide auto-discovery, doesn't support scanning (only printing), and requires the drivers on every device which you want to print from.

If you share with the router's print sharing function, you won't be able to print from smartphones or from PCs which don't have the driver installed (and sometimes you can't install it: think of Windows on ARM or macOS on M chips).