← Back to context

Comment by ValdikSS

6 hours ago

Spent about 2 years improving printing and scanning stack of Linux: CUPS, SANE, AirSane, as well as some legacy drivers, and also x86 proprietary driver emulation on ARM with Box86.

Even that "modern" printing stack in Linux is 20+ years old, there's still such an unbelievable amount of basic bugs and low-hanging-fruit optimizations, that it's kinda sad.

Not to mention that it still maintains ALL its legacy compatibility, as in supporting ≈5 different driver architectures, 4 user-selectable rasterizers (each with its own bugs and quirks).

The whole printing stack is supported by 4 people, 2 of whom are doing that since the inception of CUPS in 1999. Scanning is maintained by a single person.

Ubuntu 26.04 LTS is expected to be the last version with CUPS v2. CUPS v3 drops current printer driver architecture and introduces proper modern driverless printing with the wrapper for older drivers. Many open-source drivers are already use this wrapper, but expect a huge disarrangement from the users, as none of the proprietary drivers would work out of the box anymore.

Do you care about printing? Want to improve printing & scanning stack? Contact OpenPrinting! https://github.com/OpenPrinting/

Any relation to this project? https://www.opentools.studio

  • Nah, I got into printing because nobody made a commercially available print server, and I ended up making my own, with all the involvement in the stack in the process.

    I wish Openprinter luck, as it has been announced in the end of September but nothing out there yet, not even the crowdfunding campaign.

Great initiative. I wonder, how likely is it for a complete beginner to break their own printer or scanner by making a mistake in driver implementation? Or is it possible to work on hardware support without having a physical device? I assume it is impossible to test each and every one printer and scanner, so there is probably some clever tricks there, right?

  • I work mostly with the old microcontroller-based cheap consumer ("GDI") USB models circa 2000-2010, these are hardly possible to brick with software, as some of them even don't have a firmware and expect the PC to upload it on each power on sequence.

    The hardware safety mechanisms are usually robust (USB communication is handled by "Formatter Board", all the mechanical stuff is in the "Engine Controller" power).

    Newer Linux-based models have filesystems, software, and vulnerabilities, printer hacking on Pwn2Own is an every year common occurrence. These could be permanently bricked by the software in a common sense, and would require a firmware reflash using the bootloader or external means.

    >Or is it possible to work on hardware support without having a physical device?

    Absolutely, but for me this is very inconvenient—like the debugging over the phone.

    Sometimes the bug is as low-level as in the USB stack: https://lore.kernel.org/linux-usb/3fe845b9-1328-4b40-8b02-61...

    >I assume it is impossible to test each and every one printer and scanner, so there is probably some clever tricks there, right?

    Not much, unfortunately. There's ongoing work on modern (driverless) printer behavior emulation, but it is under heavy development and not ready yet: https://github.com/OpenPrinting/go-mfp

    Nothing for the older printers and scanners which require it's own driver, of what I'm aware.

Thank you. I have thrown printers out the literal window.

  • > Thank you. I have thrown printers out the literal window.

    I have literally thrown one of those "winmodems" [1] out of the window back in the days. I then went out and drove with my car on it. I then put it in a bench vise until its PCB shattered to pieces. Utter destruction, much to the amusement of my brothers.

    These were the days.

    And big thanks to GP for his work of CUPS / Linux printing.

    [1] https://en.wikipedia.org/wiki/Softmodem