|Did you know…?
LWN.net is a subscriber-supported publication; we rely on subscribers
By Jonathan Corbet
June 4, 2021
Back in a distant time — longer ago than he cares to admit — your editor
managed a system-administration group. At that time, most of the day-to-day
pain reliably came from two types of devices: modems and printers. Modems
plentiful than ever now, but they have disappeared into interface
controllers and (usually) manage to behave themselves. Printers, instead,
are still entirely capable of creating problems and forcing a
reconsideration of one’s life choices.
Behind the scenes, though, the situation has been getting better but, as a
recent conversation within the Fedora project made clear, taking advantage
of those improvements will require some changes and a bit of a leap of faith.
Traditionally, getting a printer working on Linux has involved, among other
things, locating and installing the appropriate printer drivers and
PostScript printer definition (PPD) files to allow
the system to communicate with the printer using whatever special
dialect it favors. Often that involves installing a separate package like
often supplied by the printer vendor.
Some vendors have traditionally supported Linux better than others, but
none of their products seem to work as smoothly as one would like.
While printer setup on
Linux has definitely improved over the years, it still easy to dread
having to make a new printer work.
The Internet Printing Protocol
In this context, it is noteworthy that the maintainers of the CUPS system,
which handles printing on Linux, have an outstanding issue
calling for the removal of its support for printer drivers. The Fedora
development list also discussed
this idea in late May. There are changes coming in the printing world,
and users are naturally curious about when and how those changes will
Those who have not been following developments
in printing may wonder why it would make sense to remove printer drivers,
since those are what make the printers actually work.
The answer is the Internet Printing Protocol (IPP) and, specifically, a
derivative called IPP
Everywhere. The idea is simple enough: what if all printers
implemented the same protocol so that any software could print to them
without the need to install special drivers or, indeed, perform any
configuration work at all? Like many things, IPP Everywhere seems to be
motivated by the desire to interoperate with smartphones, but it is useful in
a wider context as well.
In the IPP Everywhere future, printers simply work. They make themselves
known to the network via multicast DNS, allowing
other machines on the network to discover them. The protocol allows the
printer to communicate its capabilities and accept settings, so features
like duplex printing and paper-tray selection work. IPP Everywhere describes
a small set of known formats for material to be printed, so there is no
need for special drivers for format conversion. Users simply need to
indicate their desire to print something, select between the available
printers and printing options, install the new toner cartridge that the
printer inevitably demands, then file the resulting output in the recycling
bin. It’s a printing paradise.
Or, at least, it will be a printing paradise one of these days. Given that
IPP Everywhere has been around since 2010, one might think that we should
have arrived already, but there are some remaining issues.
Does it work?
CUPS has long had support for IPP Everywhere, and distributions have
generally enabled that support. But it still doesn’t seem to be the
default way to use printers on Linux. For example, a search for how to
set up your editor’s Brother laser printer on Linux results in a visit to
driver page; after a somewhat fraught process the printer can be
made to work well — but it’s not a transparent or driverless experience.
That printer is supposed to support IPP Everywhere, though, and it can be
seen in the output of avahi-browse. Android devices can
successfully print to it. That means, with any remotely modern version of
Linux, the printer should show up
automatically when trying to print a file, without the need to set up a
queue at all. It does indeed appear, but an attempt to use it results in
the print dialog hanging before
the user can even hit the “print” button. That experience may be
driverless, and it certainly results in a reduction of wasted paper, but
it’s also less than fully satisfying.
What about adding a queue explicitly? Firing up the “add a printer”
dialog on a freshly installed Fedora 34 system produces a blank window
— not the experience a printer user is looking for either. Typing in the IP
address for the printer (something most users naturally have at the tips of
their fingers) yields the display seen to the right: five
options, with no real indication of which one — if any — is correct. In
fact, only the final option in the list works at all, and it takes several
minutes to print a page, for reasons that are unclear to anybody not
initiated into the deep magic of CUPS.
If, instead, one simply tells CUPS to use the printer as an IPP Everywhere
device with a command like:
# lpadmin -p NewPrinter -E -v ipp://10.0.0.16/ipp -m everywhere
The printer works well, immediately. It began, of course, by communicating
its appetite for a new toner cartridge to the Fedora system, which duly
passed the request on. So IPP Everywhere does work, at some level, on both
ends of the connection, but some of the glue is seemingly not yet fully in
Most distributors have been working on support for driverless printing.
The curious can find instructions online for
and others. SUSE and openSUSE seem to be the biggest exception, unless
your editor’s search skills have failed.
In theory, almost all printers made in the last ten years should support
IPP Everywhere. It seems that most do, even though the list of certified printers is
conspicuously missing a number of vendors. But not everybody has a printer
that recent; printers can stay around for a long time. The removal of
printer drivers from CUPS (and the distributions using it) means the
removal of support for all of those devices. It is fair to say that
doesn’t sit well with the owners of such hardware.
The intended solution to this problem is “printer applications”: programs
that can speak to a certain class of printers while implementing the IPP
Everywhere protocol to connect those printers to CUPS. Only a handful of
those exist now; they include LPrint, which can drive a set of
printers. Work is underway to support others, including the “foo2zjs” devices that show
up as IPP Everywhere printers, but which still need special drivers to
work. Implementing more printer applications features prominently in the
Summer of Code plans this year.
This does not satisfy all users out there, many of whom got their printers
working after a fair amount of struggle and do not relish the idea of
having to go through that process again with a new system. Some worry that
there will be CUPS-supported printers that never get printer-application
support; that may well happen, but it’s not clear how many users will be
affected by the loss of support for some ancient devices. Others complain
that this transition is a lot of churn for no real benefit; Solomon Peachy
concern this way:
local drivers. CUPS-shared printers JustWork(tm), also without
local drivers. Folks with smartphones can print to most
CUPS-attached printers, again, no drivers. […]
We’re closer than ever to a universal printing system that is not
tied to any specific OS or client, and that behaves identically no
matter where or how the printer is attached. Underpinning all of
this are formally standardized protocols (and equally importantly,
well-defined behaviors), Free Software reference implementations
and conformance tests.
For many of us, that universal printing system can’t come soon enough, if
it works as well as it is intended to. Should that happen, there is likely
to be little lamentation over the loss of printer drivers.
There is one other concern that came up in the Fedora conversation, though.
In a world where printers just show up on the net, what is to prevent an
attacker from putting up fake printers in the hope of capturing documents
with interesting contents? There does not seem to have been much effort
put into addressing this scenario; as Zdenek Dohnal put
CUPS discovery is designed to run on secure, private LAN, so” Peachy added that, if an
it is expected that you have a protection against somebody connecting to
attacker has a sufficient presence on the local network to advertise a
false printer, they can probably do worse things than that.
IPP does have provisions for authentication and such, but employing them
would take away much of the convenience that the protocol is meant to
provide in the first place. So the general attitude toward security is
likely to remain as Dohnal described it: the local network is expected to
In a related issue, some participants in the discussion expressed concerns
that some IPP Everywhere devices work by routing print jobs through
cloud-based services. Indeed, the Android print dialog, when printing to
the above-mentioned Brother printer, warns that the document may pass
through third-party servers — something that does not appear to actually
happen in this case. The idea of a local printer that fails when the
Internet is down lacks appeal, but somehow we seem to be heading toward
that world anyway.
The CUPS project has been working toward a driverless future for many
years; the use of PPD files was first deprecated in
the 1.4 release in 2009, even though there was no replacement for them at
that time. The project finally deprecated
printer drivers with the 2.3 release in 2019. “Deprecated” is not the same
as “removed”, though; this deprecation was intended to draw attention to
the forthcoming change. As can be seen with PPD files (which are still
supported), there can be a long time between deprecation and removal.
That said, the plan is apparently to remove printer drivers in the next
major CUPS release, for which there does not currently appear to be a
target date. The project has not made a release since 2.3.3 came out in
April 2020, so things do not seem to be moving all that quickly there at
the moment. There is probably some time for distributors and users to
prepare for this change.
That is a good thing. Even if most printers are supported reasonably well
by IPP Everywhere, there will be a lot of users of printer drivers out
there, and a lot of users with older printers as well. There will need to
be a lot of work and testing done if the first distributions that release with
CUPS 2.4 are to not break vast numbers of printing setups. If that can be
done, though, perhaps printers can finally join modems as devices that
simply work without the need for a lot of messing around.
(Log in to post comments)