Translation(s): none

Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters.

The Concept of Driverless Printing

Driverless printing is targeted at the client side of printing and refers to the ability of the client device (computer, smartphone, tablet, laptop etc) to print without having to install any static capability files or drivers (manufacturer-specific or otherwise) on the client.

There exist a variety of methods for a client to submit a job to a printing system and print driverlessly:

This page is intended to highlight and explain driverless printing in the context of directly communicating with a printer using packages provided by Debian, so not all these methods will receive attention here. Furthermore, details for using iOS and Android mobile clients are not treated.

Remember that CUPS can act as a client or server. In its server capacity it can emulate an IPP Everywhere or Apple AirPrint printer. However, the focus here is on CUPS as a client connecting to a printer which offers driverless printing functions.

Driverless Printing and Printers

A traditional printing system based on CUPS, cups-filters and cups-browsed generally obtains information about printer features and capabilities from what is stored in a static capability file such as a PostScript Printer Description (PPD) file. This static file is stored on the client device (desktop computer, laptop, tablet etc) itself. If the PPD on the client requires the sending of a job using a non-standardised Page Description Language (PDL) a driver would be required for converting to the printer-specific PDL and that driver too would have to be on the client. A client that regularly connected to different printers would have to maintain static capability files and drivers for each printer.

This is not seen as an acceptable situation, especially for mobile clients, which may have limited storage for PPDs and drivers and which may lack resources, such as battery power. Neither is it deemed particularly realistic for a user to have to set up or reconfigure a laptop computer or mobile device for each printer that is encountered. This requires a level of expertise and a time and effort commitment that cannot be assumed to be possessed.

Then contrast the printer situation with the behaviour of other peripherals like keyboards, mice, cameras and USB mass storage. Plug such devices in and they are immediately and reliably there to be used. The objective is to have printing no less available when a printer is detected.

The response of printer manufacturers to the desire for driverless printing has been to enhance their printers in the following way:

Note again that we are talking here about sending a job directly to a printer, not to a print queue being advertised by CUPS.

PDLs for Driverless Printing

Two raster formats, Apple raster and PWG raster, have been developed to implement driverless printing.

In the case of PWG raster the raster format was chosen because it is a simpler format than that of the high-level languages, which also require significant resources on the printer. Printer-embedded PostScript interpreters can be buggy and/or slow and PostScript also has the disadvantage that it makes interoperability between client and printer difficult because PostScript does not fit cleanly with the IPP and PWG models. Streaming was chosen to send a job to a printer rather than generating a file that is downloaded and then printed. This way large jobs don't take up too much memory or storage space on the printer and printing commences with minimum delay.

CUPS: PWG and Apple Raster

The abilitity to create Apple raster files has been added to the existing PWG raster support in CUPS and made its appearence in CUPS 2.2.2; this enhancement was soon applied in version 1.13.0 of cups-filters and cups-browsed. Complete support for IPP Everywhere printers was already in Debian, so, with CUPS 2.2.2, AirPrint printers joined the class of printers that will work driverless with Debian.

With the incorporation of the two raster formats as a PDL in CUPS, IPP 2.0 to allow for querying the capabilities information from the printer and Bonjour/DNS-SD to find the printers in the network, Debian has everything needed for driverless printing to an IPP printer.

The processing of a job to create an Apple raster file is taken care of by CUPS' rastertopwg filter. The file produced by the filter is sent directly to the printer with IPP so no vendor-specific filters are involved. This opens up the possibility of avoiding the use of non-free drivers on the CUPS client or server used for printing.

Creating a Driverless Print Queue with lpadmin (Short version)

The URI of a printer:

ippfind ! --txt printer-type

The print queue:

lpadmin -p <print_queue_name> -v <URI> -E -m everywhere

Creating a Driverless Print Queue with lpadmin

Some familiarity with a device-uri is assumed in this section.

With a single AirPrint printer on the network a partial output from lpinfo -v could be:

network dnssd://HP%20ENVY%204500%20series%20%5BFAFAC2%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2
network socket://
network ipp://envy4500.local:631/ipp/print

The snmp backend has found the printer will accept jobs on port 9100 (socket://192...). Queues using this device-uri would need to be set up with a PPD specified with the -m or -P option of lpadmin, so would not be driverless.

The ENVY 4500 has also been discovered from the printer's Bonjour broadcasts using the dnssd and ipp backends. Both these URIs are equally stable and can be used for driverless printing, with a dnssd URI being preferred if the ipp URI is using a numeric IP address.

The device-uri for the printer can also be found with the ippfind or driverless utilities. ippfind locates DNS-SD advertised printers and queues. driverless (a cups-browsed utility) lists IPP printers only.

ippfind                         (Shows IPP printers and print queues).
ippfind -T 5                    (Possibly more reliable).
ippfind ! --txt printer-type    (Show IPP printers only).

driverless                  (To get the device-uri).
driverless list             (For the device-uri and printer metadata).
driverless device-uri       (Generate a PPD for the printer at device-uri).

A queue for driverless printing from a client is now set up with

lpadmin -p <print_queue_name> -v <device-uri> -E -m everywhere

The everywhere model causes the printer referred to by the -v option to be queried. A list of printer capabilities is returned and a PPD is automatically generated by CUPS for use by command line programs and applications.

If the -v option is the URI of a queue on a remote CUPS server, this technique can create a driverless queue on the client for a remote non-raw queue. This is the method employed when CUPS sets up a temporary queue on a client.

Creating a Driverless Print Queue with the CUPS Web Interface

Some familiarity with the CUPS web interface is assumed in this section.

Creating a Driverless Print Queue with system-config-printer

Some familiarity with system-config-printer is assumed in this section.

Creating a Driverless Print Queue with cups-browsed (Short version)

Edit /etc/cups/cups-browsed.conf:

CreateIPPPrinterQueues all


systemctl restart cups-browsed

Creating a Driverless Print Queue with cups-browsed

This method leads to a fully automatic discovery of an AirPrint or IPP Everywhere printer, sets up a print queue and creates a PPD for it. The PPD is used to display printer options for command line programs and in applications. There are just two operations a user has to carry out.

CreateIPPPrinterQueues all
CreateIPPPrinterQueues driverless

systemctl restart cups-browsed

lpstat -t
lpoptions -p <queue_name> -l

IPP-over-USB (Short version)


The previous methods to set up driverless printing with CUPS are network-only. They require IPP for querying the capabilities from the printer so that the PPD can be generated. They also need IPP to send option settings to the printer (as IPP attributes). Fortunately, driverless printing is not confined to the network only but also works in this way via USB using ippusbxd. A recent AirPrint printer should support IPP-over-USB.

The in /usr/share/doc/ippusbxd lays out the principles underlying the program's operation. We will look at implementing these principles in the context of exposing a printer on a dummy0 interface on a Debian 10.x.x installation and with cups-browsed running.

Set up the dummy0 interface:

ip link add dummy0 type dummy          # Load the dummy module and create a dummy interface.
ip link set dummy0 up multicast on     # Bring the interface up.
ip addr add dev dummy0 # Give the interface an unused address.

Check the existence of the interface with

ip a

It is tedious to have to do this every time the computer is switched on, so a systemd service is indicated.

Create the file /usr/local/sbin/create-dummy0:


IP=$(ip a | grep dummy0)

if [ -z "$IP" ]
        ip link add dummy0 type dummy
        ip link set dummy0 up multicast on
        ip addr add dev dummy0
else rmmod dummy

Now create /lib/systemd/system/dummy0.service:

Description=Create a dummy interface for ippusbxd




systemctl daemon-reload

The dummy0 service will be started when the machine is booted. Thereafter, control whether it is operative with

systemctl stop dummy0.service
systemctl start dummy0.service

Having exposed the printer on the dummy0 interface it should be sufficient to connect a suitable printer to a computer, switch it on and issue the command

ippusbxd -i dummy0

to have a PPD generated by cups-browsed and a permanent queue for the printer created. Check with

ls -l /etc/cups/ppd
lpstat -a
ipstat -l -e

The ippusbxd daemon is stopped and the print queue removed when the printer is turned off or disconnected from its USB cable.

Versions of cups-browsed greater than 1.14.0 have LocalOnly as the default value of CreateIPPPrinterQueues. Consequently, no adjustments are needed to /etc/cups/cups-browsed.conf to have the printer visible locally. See the cups-browsed changelog for the rationale.

Starting and stopping ippusbxd automatically to create and delete a print queue (rather than using the command line) becomes possible using the ippusbxd-provided systemd service file:

cp /usr/share/doc/ippusbxd/examples/ippusbxd@.service.dummy0 /lib/systemd/system/ippusbxd@.service
systemctl daemon-reload

Power-on and power-off the printer (or attach or detach its USB cable) to have this auto-creation of a queue. Share the queue on the local network using the CUPS web interface or do

cupsctl --share-printers
lpadmin <queue_name> -o printer-is-shared=true

You are free, of course, to follow upstream's advice and expose the printer on the localhost interface. But, until bug #909564 is resolved, you will have to patch avahi yourself.

CUPS 2.2.4 and Driverless Printing (Short version)

Display local and remote queues and printers:

lpstat -e


lp -d <queue_or_printer> <file>

CUPS 2.2.4 and Driverless Printing

CUPS' ability directly to browse the DNS-SD (Bonjour) broadcasts of remote print queues and printers, previously absent, was introduced in CUPS 2.2.4. This means that a system with CUPS 2.2.4 or later (such as Debian 10.x.x) will display remote queues and printers with lpstat -e and in the print dialogs of some applications without cups-browsed (needed on Debian 8.x.x and Debian 9.x.x for remote queue management) being on the system. No action on the part of the user is required.

Essentially, CUPS uses its CupsGetDests and CupsEnumDests functions to discover shared queues and printers which can be printed to on the local network and makes them available for display in an application. Whether or not the application displays them depends on the chosen application. Printing to an enumerated entry leads to the formation of a temporary queue.

Let us consider the behaviour of the GTK print dialog in a little more detail. The applications using it produce a PDF with libcairo2. A Debian CUPS server will have no trouble accepting and printing this PDF when it is sent to a remote queue listed in the dialog. If the entry is a remote printer the printer has to be able to accept and process the PDF. This might not be the case, so the dialog will display

print      <Location>  Rejecting Jobs

A check with avahi-browse might reveal for the printer:


showing that PDF is not an accepted Page Description Language.

The solution is to put cups-browsed on the system and, in cups-browsed.conf, have cups-browsed create permanent, local queues (rather than the CUPS temporary queues) for remote queues and printers with

UseCUPSgeneratedPPDs No

It very likely that only the entry for the remote printer is wanted, so alter cups-browsed.conf to have

CreateRemoteCUPSPrinterQueues No

Note that managing queues and printers in the GTK dialog in this way also leads to other dialogs and the command line utilities following suit.

CUPS and Driverless Printing: Miscellaneous

http://<IP_address or host name of the printer>

The hostname can be obtained from the output of avahi-browse (see below). Make sure that IPP support and Bonjour broadcasting are enabled. The configuration options will probably be accessed under a Networking link and it could be that activating AirPrint is sufficient to activate both services.

                                     ->|--------------------------------------------> Printer
text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopwg -> PWG raster ---> Printer
                                     ->| gstoraster -> rastertopwg -> Apple raster -> Printer

avahi-browse -art | less

Identify your Bonjour-advertised IPP printer and look for entries beginning URF=... and pdl=... . If URF=... exists and pdl=... contains image/urf you have an AirPrint printer.

For an HP Envy 4502:


For a Brother MFC-J650DW:

URF = SRGB24,W8,CP1,IS1,MT1-8-11,OB9,PQ4-5,RS300,OFU0,V1.2,DM3
pdl = application/octet-stream,application/,image/pwg-raster,image/urf,image/jpeg

The pdl contains an additional image/pwg-raster. This printer will accept and print PWG raster files. It could be an IPP Everywhere printer, but that all depends on whether it fulfills all the criteria necessary for the manufacturer to self-certify it with the Printer Working Group (PWG). However, it is possible the printer IPP implementation is sufficient for driverless printing to be used with CUPS.


Didier 'OdyX' Raboud <> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable. Till Kamppeter <> for his integration of cups-filters and cups-browsed with CUPS 2.2.2. Michael R. Sweet <> for developing the rastertopwg filter to support Apple raster.

See Also