LWN: Comments on "Topics from the Open Printing microconference"

Topics from the Open Printing microconference

pabs — Wed, 02 Oct 2019 12:08:40 +0000

Thanks for the reminder of basically the perfect answer to the question of why we need to reverse engineer printer firmware! I had read the recent FSF post about printer firmware but forgotten about it.

Topics from the Open Printing microconference

pizza — Wed, 02 Oct 2019 11:20:13 +0000

Given that the whole point of "IPP Everywhere" is that the "driver" is intentionally embedded into the printer's "firmware", there no longer a practical difference between the two.

But back to your question, it was the host-side driver ("firmware" as we refer to it today was quite rare in those days..)

https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt

But more recently, the FSF published another another testimonial about printer firmware:

https://www.fsf.org/blogs/community/201cthe-printer-story...

Topics from the Open Printing microconference

pabs — Wed, 02 Oct 2019 09:38:58 +0000

It isn't clear to me whether or not RMS' printer story was about printer driver or firmware, does anyone know the details?

Topics from the Open Printing microconference

seyman — Wed, 02 Oct 2019 07:35:03 +0000

> All the usual reasons for wanting Free Software on your devices apply to printers too;

Given that the Free Software thing started when RMS was confronted with a closed-source firmware on a printer and was refused a copy so that he could improve it, I would expect printer firmware to be a first-class citizen.

Topics from the Open Printing microconference

pabs — Wed, 02 Oct 2019 01:14:19 +0000

I would have thought that clear to LWN readers but a few thoughts:

All the usual reasons for wanting Free Software on your devices apply to printers too; so that we can fix bugs, add features, improve performance etc.

Various people dislike having their data be sent to inscrutable proprietary devices, that includes printers too.

Printer firmware has been shown to be traitorous to printer owners:

https://web.archive.org/web/http://seeingyellow.com/
https://en.wikipedia.org/wiki/Printer_steganography

Topics from the Open Printing microconference

pizza — Tue, 01 Oct 2019 20:10:41 +0000

Not speaking to this specific instance, but RE work often leads to extra exposed functionality, including more control over the output -- which really matters to certain users and their use cases.

(Plus you and I are both painfully aware of how buggy printer firmware can be, even when it's not being actively targeted by bots)

New OpenPrinting web site

tillkamppeter — Tue, 01 Oct 2019 19:57:35 +0000

By the way, I have switched over the OpenPrinting web site to the new design.

Topics from the Open Printing microconference

tillkamppeter — Tue, 01 Oct 2019 19:24:41 +0000

There is already such and approach to convert classic filter+PPD drivers to Printer Applications, a GSoC project of this year: Printer Applications Framework

Topics from the Open Printing microconference

tillkamppeter — Tue, 01 Oct 2019 19:03:29 +0000

The Linux driver for IPP-over-USB is the OpenPrinting project ippusbxd. This started as a GSoC project, by the way.

Topics from the Open Printing microconference

tillkamppeter — Tue, 01 Oct 2019 18:57:51 +0000

Why do you want to reverse-engineer printer firmware? Driverless printing follows open standards and so the client software can be written without knowing the source of the printer firmware. Also driverless IPP printers are common and cheap currently, so hacking an old printer to get driverless would not be worthwhile.

Topics from the Open Printing microconference

Cyberax — Fri, 20 Sep 2019 20:55:59 +0000

First, Bill Gates has no authority whatsoever to prohibit RS-232 ports. I think they simply dropped RS-232 from required hardware for "Windows PC".

Second, USB-to-Serial converters have been available since 1997.

Third, if USB-to-Serial is insufficient for some obscure reason (timing, etc.), fully compliant RS-232 PCI cards are widely available to this day. They're selling for $20 or so.

Topics from the Open Printing microconference

Wol — Fri, 20 Sep 2019 20:48:01 +0000

My HP business MFP works fine. CUPS has no problems printing to it, although as another person said I found lpr much easier ...

But for scanning, I always use "scan to share" so there are no drivers or anything on the linux side. Just samba. Although one of my users just refuses to work and I haven't a clue why.

That user has no problems connecting from elsewhere.

Cheers,
Wol

Topics from the Open Printing microconference

Wol — Fri, 20 Sep 2019 20:37:45 +0000

> That's just the usual stragglers, in niche markets, that use the fact they are in a low-competition niche to delay change as long as possible (the same swore they would never use USB when it was introduced).

This is the same problem as when Bill Gates told manufacturers to drop RS-232 ports from PCs, and various END USERS complained. BG's response was "well buy new peripherals then!". When the end user has 10 peripherals at $1/4M *each*!

It's not the manufacturers stalling, it's end users not wanting to write off a LARGE investment just because somebody else wants to make a fast buck.

Cheers,
Wol

Topics from the Open Printing microconference

niner — Mon, 16 Sep 2019 19:33:44 +0000

Except when they don't. I happen to own such an HP laser printer/scanner. For the first year or so the online print service was the only way for me to get any printed result out of the thing despite HP offering Linux drivers on the website. Then the online service stopped working and despite me proving to support that it was a change in their online service (switch to https) that killed my printer, they did nothing to fix this. At least that spurred me to try to find a way to print locally and indeed I succeeded. By using the PPD of a different printer, not the one that was meant exactly for my model.

Topics from the Open Printing microconference

pizza — Mon, 16 Sep 2019 13:15:27 +0000

> They will build up technical stress by resisting change, till it reaches the rupture point, and then brutally realign with the rest on the market in a destructive earthquake.

One other thing -- For the most part, native IPP support is never going to happen on most of those niche verticals, because it will require a substantial increase in hardware BOM and a non-trivial NRE investment, and in return they will get a system that is slower, less flexible, and still requires a host system to run arbitrary user applications.

What's actually happening in this market is that the printers are remaining relatively dumb, but for users that care about network printing features, most of the manufacturers sell a bolt-on "print server" box that can drive several attached printers. Those little "print server" boxes are all running.. wait for it.. Linux, CUPS, and that "deprecated" F/OSS driver stack, resulting in a fully functional IPP printer that JustWorks(tm). Well, with everything but Apple Airprint clients, because AirPrint isn't quite IPP compatible.

IPP doesn't magically eliminate the need for a driver to be written; it just pushes it from the client-side to the server.

But right now, even for folks that want to do the right Future Proofed thing, the most functional "IPP printer driver framework" is actually Legacy CUPS. By a wide, wide margin.

Topics from the Open Printing microconference

pizza — Mon, 16 Sep 2019 12:26:17 +0000

> They will build up technical stress by resisting change, till it reaches the rupture point, and then brutally realign with the rest on the market in a destructive earthquake.

Those manufacturers, for the most part, have always used "printing applications" as their primary target. Invariably in the form of a Windows DLL that requires end-user applications to explicitly code against. Some of the more progressive makers provided a Linux .so equivalent. So all of this CUPS/IPP stuff is completely irrelevant to them and their target markets.

Ironically, it's the F/OSS advocates that are getting screwed here; the ones who reverse-engineered these printers to write F/OSS CUPS drivers so they could use their own hardware and print without a Windows license. The system integrators who built their solutions on F/OSS platforms that use standardized discovery/configuration/queueing/printing APIs (ie "legacy CUPS") to break vendor lock-in and enable non-WinTel embedded platforms.

The most likely outcome here is that CUPS will get forked (most likely by the OpenPrinting folks) and all of the things that CUPS dropped support for over the years (because they only matter to organizations-not-named-Apple) will get re-integrated.

I consider this a GoodThing, and OpenPrinting has repeatedly shown themselves to be competent stewards.

Topics from the Open Printing microconference

nim-nim — Mon, 16 Sep 2019 08:48:56 +0000

Neither me, nor the cups folks, write those users do not matter from a market POW.

However, from a technical progress POW, those manufacturers definitely do not matter. They're the last 5% of the adoption curve, the very conservative minority that does not want to invest any effort into changing, and would rather invest twice the amount of time, money, and energy, into making the past live a little longer, than take the risk of building their bit of the future. (I actually work in such a company so I know the mindset very well).

They will build up technical stress by resisting change, till it reaches the rupture point, and then brutally realign with the rest on the market in a destructive earthquake.

I'm sure the cups maintainers would love to design with them a future that addressed their use cases, except there is no one to work with. By the time those companies will be interested in looking at the problems the design will have been done with others.

Topics from the Open Printing microconference

pizza — Fri, 13 Sep 2019 17:30:29 +0000

You're taking the same dismissive "those users don't matter" attitude as the CUPS folks, which doesn't help anyone.

I'm not saying that we shouldn't try to improve the general status quo, or improve the user experience for the common 98% -- But we have to keep in mind that we shouldn't actively preclude the remaining 2% from being able to do what they need -- because for that 2%, printing is not just a convenience, or a even necessary evil -- Instead, it is the entire point of their business.

(Just one of those "niche" verticals (photo kiosks) represents a $1.5 billion worldwide market, made of mostly of pretty small players. Those are my users; the actual equipment manufacturers tend to be more of a hinderance than anything else..)

Topics from the Open Printing microconference

pizza — Fri, 13 Sep 2019 16:59:25 +0000

I actually agree with what you wrote, but if that's their plan, they have yet to express it or give any specifics solid enough to act upon.

Topics from the Open Printing microconference

nim-nim — Fri, 13 Sep 2019 16:25:48 +0000

A lot of "business" scanner/printers will mail scan results to configurable addresses. Just buy one of those when Lexmark or HP or whatever empties inventory and makes a sale. If it's a laser it will probably end up cheaper than a consumer inkjet that dies up every other week. IPP for printing + mail pdf for scan = driver-less no-hassle printer that will still work in ten years.

The main drawbacks are they are ugly as hell (business unbreakable gray plastic, not shiny consumer brittleware), and they tend to take more space (they don't pretend a 10-sheet paper tray is enough for your needs). They need to hide below a pretty scarf at home.

Topics from the Open Printing microconference

nim-nim — Fri, 13 Sep 2019 16:16:00 +0000

That's just the usual stragglers, in niche markets, that use the fact they are in a low-competition niche to delay change as long as possible (the same swore they would never use USB when it was introduced).

They'll keep at it as long as no competitor makes the switch. If they manage to procrastinate long enough, and customers get fed up enough with the aggravation, there will be the usual extinction event when a fixed product appears, and market dries up for anything else.

Topics from the Open Printing microconference

nim-nim — Fri, 13 Sep 2019 16:07:05 +0000

Yes, that's exactly what I meant.

Networking has become cheap and reliable enough, including consumer-side via wifi, that printers, and a lot of other things that used to be devices, are graduating to appliances (and a lot of things that never were devices are graduating to appliances too).

That completely changes the landscape, because:
– appliances are autonomous, and do not need a computer to be driven (they can be managed via dumb buttons, cloud connexion, smartphones, alexa, etc)
– the network is shared by many networked things (some definitely not trusted)
– many clients can talk to the appliance in parallel, it's no longer a master-slave 1:1 relationship

That means that instead of designing custom serial, parallel, or whatever protocols, people need to design networking APIs, with strong auth and encryption, and multi-client handling.

The mental and trust model is not the same, and of course people will try to emulate the old device model over networks as long as possible, but mid term it's deader than dead.

And, we'll soon see a replay of the bad old protocol wars, this time network API side.

Topics from the Open Printing microconference

luto — Fri, 13 Sep 2019 15:09:02 +0000

ISTM it would make sense for CUPS to be able to run an unmodified legacy printer driver in a sandbox and expose the result as a "Printer Application". I see no fundamental reason that the drivers actually need to be rewritten one by one to continue working.

Topics from the Open Printing microconference

niner — Fri, 13 Sep 2019 07:17:44 +0000

I'm pretty sure nim-nim meant that a printer is not a device that you plug in to your computer and that is then controlled by this computer but really it's own computer that's attached to the network and communicates as an equal.

Topics from the Open Printing microconference

draco — Fri, 13 Sep 2019 03:34:06 +0000

When CUPS first replaced lprng, I remember thinking it was pretty good (I think because the configuration tools did a pretty good job).

But it seems to get more and more brittle with every upgrade, and I always seem to run into problems no one else seems to share...or if I do find people with my problem, I never find that they had solutions that fixed anything. (A common fix is to delete the printer and re-add it.)

This past weekend, I reinstalled the machine that hosts my printer for my network and despite having a full system backup available, I still managed to break printing completely. After hours and hours, I finally managed to claw back to a working state, but it took a lot of guessing from useless error messages. (Turns out that configuring a remote printer to use the print drivers is a huge mistake that the configuration UIs encourage you to make. I suspect that people are deleting printers and re-adding them with a different configuration without even realizing it...)

Just now, I remembered that I left debug logging on (practically worthless, it turns out), so I went to the web admin interface to shut it off. Click to apply the change, and....the server stops and doesn't come back up until I manually restart it by hand. That worked on my client machine, but on the server machine the "apply changes" just hung, so I had to manually edit the config and restart it.

When I first got into Linux, the received wisdom of the sysadmins was that printers are the devil. Still true.

Topics from the Open Printing microconference

pabs — Fri, 13 Sep 2019 02:06:36 +0000

What do you mean by "device"? A printer is a device by any definition of the word that I can think of.

Topics from the Open Printing microconference

pizza — Thu, 12 Sep 2019 21:27:21 +0000

I'm familiar with those slides, but the "Printer Application" side of "CUPS Modular" still only exists as slideware, and there is still no migration path for an existing CUPS+PPD driver other than "completely rewrite it, possibly using the ippsample codebase as an incomplete reference"

Yes, I know ippsample recently gained a proper "emulate a printer" utility, but it has a long, long way to go before it is is functionally equivalent to what legacy CUPS already provides to drivers.

(Not to knock the years of work of the PWG and OpenPrinting folks, but Gutenprint's general userbase is nearly perfectly aligned with that 2% "holdout industrial/vertical" segment of the overall printer market that the slide deck references. Moving away from CUPS+PPD will bring us many benefits, but it will require a substantial amount of work, and we need to have something concrete to target with our very-much-in-our-spare-time efforts)

Topics from the Open Printing microconference

Cyberax — Thu, 12 Sep 2019 18:10:09 +0000

It works perfectly fine. The OTA protocol is completely vendor-agnostic.

For example, I have Halo fire alarms that are using ZigBee. The company that produced them no longer exists, but I have several spares. I've recently installed a new one to replace an alarm that was damaged by contractors, and its firmware got updated automatically by my hub.

Topics from the Open Printing microconference

kpfleming — Thu, 12 Sep 2019 16:42:53 +0000

In order to get scanning from my Brother MFC device working I had to setup an internal FTP server and configure the printer for "Scan to FTP". No amount of fiddling with the Brother-provided drivers for SANE ever resulted in a working configuration. To be honest though this has worked out pretty well, because the scans go onto our NAS and then get moved to archive directories after renaming :-)

Driverless with firmware upgrade

korobkin — Thu, 12 Sep 2019 16:04:32 +0000

In my experience driveless situation is miserable with every vendor. You basically get to choose paper, color, duplex and number of copies, and that's it. No stapling, no secure printing, no punching, nothing that is useful but printer-specific is available.

Topics from the Open Printing microconference

joib — Thu, 12 Sep 2019 14:24:53 +0000

Thanks for the link to the presentation, that clears it up. So IIUIC the big difference between the current state and the future is that all the cups code is split up into several daemons:

- currently, cupsd does everything (well, cups-browsed was split out into a separate daemon some years ago)

- in the future, there will be 3:
- 1. the client daemon, which essentially keeps track of ipp mdns/DNS-SD printer announcements. Speaks only ipp.
- 2. the sharing daemon, for enterprise etc. setups, that handles acl's, accounting, authentication etc. Also speaks only ipp + the ipp sharing extensions.
- 3. the printer applications, which handle non-ipp printers and present them as ipp printers.

Is this roughly correct?

Topics from the Open Printing microconference

luto — Thu, 12 Sep 2019 14:16:15 +0000

I assume the major benefit is support of “CUPS Modular” — see a few slides above. CUPS will finally work without a system daemon! If a “printer application” can be run in a sandbox by anyone, then the overall model becomes much nicer.

While I appreciate that CUPS supports many printers, the current overall architecture is miserable to work with. The new model should be much nicer.

Topics from the Open Printing microconference

pizza — Thu, 12 Sep 2019 13:49:07 +0000

> The plan seems to be to build "Printer Applications" to wrap the classic printer drivers and present an IPP interface to CUPS. Not sure how this would work, but I'd think such printer applications would need to reimplement a lot of functionality that is currently present in CUPS (device discovery, network/USB I/O, etc). I fear that this will never work properly...

Exactly! I have a hard time seeing how this hypothetical "printer application" can be functionally different from "CUPS minus all client support" -- especially if it expects to wrap existing, unmodified CUPS(+PPD) drivers. (And if that's essentially the plan.. what, exactly, is the point of forking CUPS into separate "client" and "server" versions?)

Don't get me wrong, there are a lot of warts with the current PPD-based driver model, especially with respect to printer status reporting and the ability to restrict option combinations based on printer configuration or loaded media..

Topics from the Open Printing microconference

pdewacht — Thu, 12 Sep 2019 13:28:42 +0000

This presentation gives some more info on the future directions of CUPS.

Particularly notable is this: "We hope to remove printer driver support in the CUPS feature release following 2.3.x"

It's easy to say that "anything in the last four or five years should work" with driverless printing, but most people & companies around here are not in the habit of replacing their printers every five year. Even low-end consumer laser printers seem to easily last 10+ years.

The plan seems to be to build "Printer Applications" to wrap the classic printer drivers and present an IPP interface to CUPS. Not sure how this would work, but I'd think such printer applications would need to reimplement a lot of functionality that is currently present in CUPS (device discovery, network/USB I/O, etc). I fear that this will never work properly...

Topics from the Open Printing microconference

Tov — Thu, 12 Sep 2019 12:28:27 +0000

Yeah, but good luck getting the bulbs updated when using a bridge and app from a different vendor...

Topics from the Open Printing microconference

pizza — Thu, 12 Sep 2019 12:21:39 +0000

"IPP-over-USB" is a real and standardized thing, and there is an existing F/OSS Linux driver implementing it and I've personally seen printers that claim to support it.

In defence of the "IPP everywhere" folks, practically every "traditional home or office" printer sold in the last five years is network enabled and supports IPP. The higher-end has supported network printing via PDF or whatnot for even longer.

But you're also right, "Deprecation of PPD files" is actually an euphemism for "We intend to drop support for everything that's not a remote IPP printer, making CUPS into just an IPP print client" (And note that all IPP printers are "remote" in this context)

So any locally-attached printers will require a new "Native IPP driver" written for that printer in order to continue operating. Which is pretty hilarious, given that the current "deprecated" CUPS+PPD model already makes these printers IPP-enabled, and that a true "native IPP driver" will require re-implementing 3/4ths of this "deprecated" CUPS functionality. (ie the entire IPP stack, job spooling, user authentication/management, bidirectionally mapping printer features to PPD^H^H^HIPP attributes, printer status reporting, daemonization, process control, logging, etc etc etc..)

That said, the space I operate in (high end, commercial-use [1] printers) rarely has anything network-enabled, and when it is, it's just an alternative transport for the same protocol spoken over USB, inevitably tied to some kind of proprietary "app" or SDK. Meanwhile, the current trend is to actually make these specialized printers _dumber_ by offloading more processing onto the host.

So yeah, this "IPP or bust" model is great for random consumer of office-type printing, but not only does it ignore the use cases of more specialized or commercial niches that the "deprecated" CUPS model serves quite effectively (even only if just as a raw spooler) it also tells those users that they're going to be kicked overboard without so much as a proverbial life raft.

[1] Printers used to make money; eg dyesub printers routinely found in photobooths or drugstore kiosks, thermal printers in ultrasound workstations, receipt printers, or inkjets that have highly specialized inksets for printing on different media, including PCBs, wide-format outdoor signage or direct-to-garment printing.. these things have lifecycles that routinely exceed a decade, and place strong emphasis on backwards compatibility with older models. Because rewriting working software is _expensive_

Driverless with firmware upgrade

zdzichu — Thu, 12 Sep 2019 12:11:37 +0000

How's the driverless situation is with other vendors? I got a HP M1132 MFP from 2015, which requires downloading binary blob ("hp-plugin") every time hplip gets upgraded.

Topics from the Open Printing microconference

joib — Thu, 12 Sep 2019 11:35:15 +0000

From https://www.pwg.org/ipp/everywhere.html :

"A PWG standard that allows personal computers and mobile devices to find and print to networked and USB printers without using vendor-specific software."

Further, in the FAQ https://www.pwg.org/ipp/evefaq.html it says

"The USB-IF developed the IPP USB Specification which allows printers to support IPP Everywhere over USB. Printers supporting IPP USB have been available since late 2013."

(No personal experience though, just copy-pasting from the interwebs.)

Topics from the Open Printing microconference

joib — Thu, 12 Sep 2019 11:28:03 +0000

In "enterprise" environments etc. printers are typically on a separate subnet, and clients never directly connect to the printer but via a print server.

I've never used IPP everywhere, but from a quick glance at the website (https://www.pwg.org/ipp/everywhere.html ), there seems to be something like "IPP Shared Infrastructure Extensions" that caters to this kind of use case.

(While CUPS has occasionally caused grey hairs, compared to the "good ole days" of configuring lpr(ng) it's always been a breeze for me)

Topics from the Open Printing microconference

draco — Thu, 12 Sep 2019 11:04:50 +0000

Historically, printer security has been pretty poor. I've always seeen attaching your printer directly to the network as security risk.

(On the flip side, getting CUPS to work with my printer(s) is by far my most dreaded administration task.)

Has the security situation significantly changed? How can I be certain that my printer is secure & up-to-date enough to be allowed to sit on my network directly?