Differences between revisions 51 and 75 (spanning 24 versions)
Revision 51 as of 2020-07-30 11:04:18
Size: 37167
Editor: Brian Potkin
Comment: Corrected misconception about suffix added to DNS-SDname. cups now recommends ipp-usb. Altered a link. Empasis. Text additions. Link added. Anchor.
Revision 75 as of 2022-07-04 22:53:57
Size: 44925
Editor: Brian Potkin
Comment: Quirk rules. Non-working 7/1/4 interfaces. Some other small additions.
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
----Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. Debian 10 (buster) and later installations meet both these conditions. The [[QuickPrintQueuesCUPS|advice here]] and [[#ippoverusb|here]] could get your modern IPP printer going with little effort. ----Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. Debian 10 (buster) and later installations meet both these conditions. The [[CUPSQuickPrintQueues|advice here]] (an ethernet or wireless connection) and [[#ippoverusb|here]] (a USB connection) could get your modern IPP printer going with little effort.
Line 9: Line 9:
<<Anchor(intro)>>
=== Introduction ===

Driverless printing requires a [[CUPSQuickPrintQueues#intro|modern]] printer. A user can be assured of having such a device when it is network-capable and it is
 * [[https://support.apple.com/en-gb/HT201311|AirPrint-certified]], or
 * [[https://mopria.org/certified-products|Mopria-certified]].

A Mopria-certified device calls for [[#pdls|PWG raster]], [[#generator2|PCLm]] or PDF to be available as a PDL. However, it is observed that almost all PCLm, PWG raster or PDF printers also support Apple raster. Therefore, AirPrint-capability is a sufficient criterion regarding whether a printer can be operated driverlessly on Debian. Just look for ''!AirPrint'' on the box or in the literature. [[https://openprinting.github.io/|OpenPrinting]] has a [[https://openprinting.github.io/printers/|list of driverless printers]].

It would be unusual for a network printer not to provide a USB connection too. In that case, the printer would almost certainly offer the [[#ippoverusb|IPP-over-USB protocol]] if it has been manufactured after mid-2012.

Debian 11 (bullseye) is geared up to auto-setup [[CUPSQuickPrintQueues|network]] and [[#ipp-usb|USB]] print queues with [[#cupsbrowsed|cups-browsed]]. Should auto-set fail and debugging cups-browsed is an unattactive proposition or there is a more complex situation to resolve, a manual queue setup with [[#shortlpadmin|lpadmin]], the [[#webinterface|CUPS web interface]] or [[#scp|system-config-printer]] is recommended.

Driverless printing for CUPS and cups-filters is [[https://github.com/OpenPrinting/cups/issues/103|here to stay]]. While it will be sone time before CUPS 3.0 enters a stable Debian distribution, an interested user may want to become aware of changes planned by the [[https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-plenary-may-2021.pdf|CUPS]] and [[https://openprinting.github.io/documentation/01-printer-application/|cups-filters]] developers.





Line 10: Line 30:
Line 13: Line 32:
''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 [[#driverless|static capability files or drivers]] (manufacturer-specific or otherwise) on the client. [[https://openprinting.github.io/driverless/|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 [[#driverless|static capability files or drivers]] (manufacturer-specific or otherwise) on the client.
Line 20: Line 39:

 * Use a cloud service such as [[GoogleCloudPrint|Google Cloud Print (GCP)]].
Line 37: Line 54:
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 [[PrintQueuesCUPS#ppd|PostScript Printer Description]] (PPD) file. 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 [[CUPSPrintQueues#ppd|PostScript Printer Description]] (PPD) file.
Line 56: Line 73:
 * There is a common [[PrintingGlossaryandIndex#pdl|PDL]] that the client can send and that the printer will accept. The common PDL is based on what is obtained from the capability information for the selected printer. A driverless-enabled printer will offer at least one of [[#pdls|Apple raster, PWG raster]], PDF or [[#misc|PCLm]] as a PDL.  * There is a common [[PrintingGlossaryandIndex#pdl|PDL]] that the client can send and that the printer will accept. The common PDL is based on what is obtained from the capability information for the selected printer. A driverless-enabled printer will offer at least one of [[#pdls|Apple raster, PWG raster]], PDF or [[#generator2|PCLm]] as a PDL.
Line 77: Line 94:
The abilitity to create Apple raster files has been added to the existing [[IPPEverywhere|PWG raster support]] in CUPS and made its appearence in [[DebianList:debian-printing/2017/01/msg00029.html|CUPS 2.2.2]]; this enhancement was soon applied in version 1.13.0 of cups-filters and cups-browsed. The abilitity to create Apple raster files has been added to the existing [[IPPEverywhere|PWG raster support]] in CUPS and made its appearance in [[DebianList:debian-printing/2017/01/msg00029.html|CUPS 2.2.2]]; this enhancement was soon applied in version 1.13.0 of cups-filters and cups-browsed.
Line 85: Line 102:
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 [[PrintQueuesCUPS#avoiding|avoiding the use of non-free drivers]] on the CUPS client or server used for printing.
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 [[CUPSPrintQueues#avoiding|avoiding the use of non-free drivers]] on the CUPS client or server used for printing.
Line 151: Line 168:
or
lpadmin -p <print_queue_name> -v $(driverless) -E -m everywhere
Line 159: Line 174:
or
lpadmin -p <print_queue_name> -v $(driverless) -m driverless:$(driverless)
Line 166: Line 179:
Some familiarity with a [[PrintQueuesCUPS#deviceuri|device-uri]] is assumed in this section. Some familiarity with a [[CUPSPrintQueues#deviceuri|device-uri]] is assumed in this section.
Line 176: Line 189:
The [[DebianMan:cups-snmp|snmp backend]] has found the printer will accept jobs on [[PrintQueuesCUPS#networkuri|port 9100]] (''socket://192...''). The [[DebianMan:cups-snmp|snmp backend]] has found the printer will accept jobs on [[CUPSPrintQueues#networkuri|port 9100]] (''socket://192...'').
Line 179: Line 192:
The ENVY 4500 has also been discovered from the printer's [[PrintingGlossaryandIndex#dnssd|Bonjour]] broadcasts using the [[PrintQueuesCUPS#dnssd|dnssd]] and [[PrintQueuesCUPS#networkuri|ipp]] backends. The ENVY 4500 has also been discovered from the printer's [[PrintingGlossaryandIndex#dnssd|Bonjour]] broadcasts using the [[CUPSPrintQueues#dnssd|dnssd]] and [[CUPSPrintQueues#networkuri|ipp]] backends.
Line 183: Line 196:
`ippfind` locates DNS-SD advertised printers and queues.
`driverless` (a cups-filters utility) lists IPP printers only.
`ippfind` locates DNS-SD advertised printers and queues. `driverless` (a cups-filters utility) lists [[https://lists.linuxfoundation.org/pipermail/printing-architecture/2021/004048.html|IPP printers only]].
Line 204: Line 216:
It might be preferred to have the [[#generator2|PPD generated by cups-filters]], so first find the ''driver URI'' (''driverless:ipp://...'') with It may be preferred to have the [[#generator2|PPD generated by cups-filters]], so first find the ''driver URI'' (''driverless:ipp://...'') with
Line 217: Line 229:
This is the method employed when CUPS sets up a [[PrintQueuesCUPS#tempq|temporary queue]] on a client. This is the method employed when CUPS sets up a [[CUPSPrintQueues#tempq|temporary queue]] on a client.
Line 222: Line 234:
Some familiarity with the [[PrintQueuesCUPS#webinterface|CUPS web interface]] is assumed in this section. Some familiarity with the [[CUPSPrintQueues#webinterface|CUPS web interface]] is assumed in this section.
Line 230: Line 242:
 * Under ''Model'' there should be an option of ''driverless, cups-filters''. This option uses the [[#generator2|cups-filters PPD generator]]. Select and activate ''Add Printer''.

 * Users who prefer to use the [[#generator1|cups-filters PPD generator]] could be better off starting the above procedure by choosing ''Find New Printers'' from ''Administration''.
 * Under ''Model'' there should be options of ''IPP Everywhere'' and ''driverless, cups-filters''. The first option uses the [[#generator1|CUPS PPD generator]] and the second the [[#generator2|cups-filters PPD generator]]. Select and activate ''Add Printer''.
Line 237: Line 247:
Some familiarity with [[PrintQueuesCUPS#scp|system-config-printer]] is assumed in this section. Some familiarity with [[CUPSPrintQueues#scp|system-config-printer]] is assumed in this section.
Line 256: Line 266:
Restart: Restart cups-browsed:
Line 263: Line 273:
cups-browsed version 1.27.1 changed the default for ''CreateIPPPrinterQueues'' to ''All''. Considering that cups-browsed is a recommended package for DebianPkg:cups-daemon, this change should lead to making IPP printers immediately visible and available. cups-browsed version 1.27.1 changed the default for ''CreateIPPPrinterQueues'' to ''All''. Considering that cups-browsed is a recommended package for  DebianPkg:cups-daemon, this change should lead to making IPP printers immediately visible and available on a bullseye installation.
Line 281: Line 291:
cups-browsed version 1.27.1 changed the default for ''CreateIPPPrinterQueues'' to ''All''. Considering that cups-browsed is a recommended package for DebianPkg:cups-daemon, this change should lead to making IPP printers immediately visible and available. cups-browsed version 1.27.1 changed the default for ''CreateIPPPrinterQueues'' to ''All''. Considering that cups-browsed is a recommended package for DebianPkg:cups-daemon, this change should lead to making IPP printers immediately visible and available on a bullseye installation.
Line 301: Line 311:
Fortunately, driverless printing is [[#debian|not confined to the network only]] but also [[#troubleshooting|works in exactly the same way via USB]] using the IPP-over-USB daemon, DebianPkg:ipp-usb. DebianMan:ipp-usb serves for using the device via USB; this is fully independent of whether there is also a network connection available between the computer and the printer. A recent AirPrint printer [[https://lists.cups.org/pipermail/cups/2018-September/074272.html|should support]] IPP-over-USB. The support situation regarding USB-only IPP printers has yet to be completely clarified. Fortunately, driverless printing is [[#ipp-usb|not confined to the network only]] but also [[#troubleshooting|works in exactly the same way via USB]] using the IPP-over-USB daemon, DebianPkg:ipp-usb. DebianMan:ipp-usb serves for using the device via USB; this is fully independent of whether there is also a network connection available between the computer and the printer. A recent AirPrint printer [[https://lists.cups.org/pipermail/cups/2018-September/074272.html|should support]] IPP-over-USB. The support situation regarding USB-only [[#intro|post-2012]] printers has yet to be completely clarified, but it is known that such devices are not guaranteed to understand the protocol.
Line 305: Line 315:
It should be straightforward and reliable to use a printer or multi-function device via ethernet or !WiFi and, in general, this is the recommended type of connection to employ. Also, such network connections allow easy sharing of the device. Some reasons why a user may want or have a preference for a USB connected [[PrintingGlossaryandIndex#mfd|MFD]] or [[PrintingGlossaryandIndex#printer|printer]] are:

 * A local network does not exist and WikiPedia:Wi-Fi_Direct is not offered by the device.
{{{#!wiki note
The previous sentence indicates that users employing the [[SystemPrinting#webinterface|CUPS web interface]] or [[SystemPrinting#scp|system-config-printer]] should be looking under network printers to establish a connection with the printer.See SystemPrinting for more detail.
}}}

It should be straightforward and reliable to use a printer or multi-function device via ethernet or WiFi and, in general, there are advantages to this type of connection. Some reasons why a user may want or have a preference for a USB connected [[PrintingGlossaryandIndex#mfd|MFD]] or [[PrintingGlossaryandIndex#printer|printer]] are:

 * A local network does not exist and [[WikiPedia:Wi-Fi_Direct|Wi-Fi Direct]] is not offered by the device.
Line 319: Line 333:
Whether a printer can use IPP-over-USB may be determined by executing `lsusb -v|less` and searching for the lines containing ''bInterfaceClass.*7''. A ''bInterfaceProtocol'' line should be found a few lines below each ''bInterfaceClass'' line.

A value of ''4'' for ''bInterfaceProtocol'' indicates a USB IPP device.
}}}

<<Anchor(debian)>>
=== IPP-over-USB: Debian 11 (bullseye) ===
Whether a printer can use IPP-over-USB may be determined by executing `lsusb -v|less` and searching for the lines containing ''bInterfaceClass.*7''. A ''bInterfaceProtocol'' line should be found a few lines below each ''bInterfaceClass'' line. Look for ''bInterfaceProtocol 4''.

Alternatively, execute `lsusb -v | grep -A 3 bInterfaceClass.*7`


A value of ''4'' for ''bInterfaceProtocol'' indicates a USB IPP device:

bInterfaceClass 7 Printer<<BR>>
bInterfaceSubClass 1 Printer<<BR>>
bInterfaceProtocol 4<<BR>>
iInterface 0

The interface is usually referred to as being a 7/1/4 one
.
}}}

<<Anchor(debian)>> /* in case of legacy links */
<<Anchor(ipp-usb
)>>
=== IPP-over-USB: Automatic Discovery and Setup ===
Line 332: Line 356:
'''Note that IPP-over-USB reserves the USB interface connection with the printer/scanner exclusively for itself and communication with a printer/scanner device by software that does not operate using the IPP-over-USB protocol becomes impossible while ipp-usb is running.''' For example, a print queue for an HP MFD can be set up with a [[CUPSPrintQueues|vendor driver and PPD]], but printing to it will not take place because the software does not use the IPP-over-USB protocol. The same holds true for all other drivers, free or non-free. '''Only driverless print queues''' [[#byhand|will work with IPP-over-USB.]] It would be as well to remove existing queues based on vendor drivers to avoid the appearance of non-working queues in print dialogs. Removing vendor packages (free or non-free) from the system is also [[#vendor|something to consider]].

Communicating with a USB connected scanner via classic SANE backends such as DebianPkg:libsane-hpaio, DebianMan:sane-pixma or DebianMan:sane-epson2 also becomes impossible with the ipp-usb daemon active and running. Expecting the non-free Brother and Samsung backends to work would also be unreasonable. A good solution to have reliable scanning is to install the independent SANE backend, DebianPkg:sane-airscan (awaiting uploading to unstable). It is an alternative to the official SANE backend, sane-escl (which as yet is not in unstable). DebianMan:sane-airscan is a highly regarded backend that interworks with IPP-over-USB very well. A non-working [[Scanner|SANE backend]] may be made invisible to a [[Scanner#front|frontend]] by commenting out the appropriate entry in ''/etc/sane.d/dll.conf'' or ''/etc/sane.d/dll.d''.
'''Note that IPP-over-USB reserves the USB interface connection with the printer/scanner [[https://github.com/OpenPrinting/ipp-usb/issues/28|exclusively for itself]] and communication with a printer/scanner device by software that does not operate using the IPP-over-USB protocol becomes impossible while ipp-usb is running. This is a consequence of the design of USB communication. It is not a bug in `ipp-usb`.'''

 *
For example, a print queue for an HP MFD can be set up with a [[CUPSPrintQueues|vendor driver and PPD]], but printing to it will not take place because the software does not use the IPP-over-USB protocol. The same holds true for all other drivers, free or non-free. '''Only driverless print queues''' [[#byhand|will work with IPP-over-USB.]] It would be as well to remove existing queues based on vendor drivers to avoid the appearance of non-working queues in print dialogs. Removing vendor packages (free or non-free) from the system is also [[#vendor|something to consider]].

'''Communicating with a USB connected scanner via classic SANE backends such as DebianPkg:libsane-hpaio, DebianMan:sane-pixma or DebianMan:sane-epson2 also becomes impossible with the ipp-usb daemon active and running'''.

 *
Expecting the non-free Brother and Samsung backends to work would also be unreasonable. '''Only driverless backends''' [[SaneOverNetwork#escl|will work with IPP-over-USB]]. A good solution to have reliable scanning with IPP is to install the independent SANE backend, DebianPkg:sane-airscan, in addition to the official SANE backend,[[DebianPkg:libsane1|sane-escl]], that comes with DebianPkg:libsane1. [[SaneOverNetwork#escl|sane-airscan]] is a highly regarded backend that interworks with IPP-over-USB very well. A non-working [[Scanner|SANE backend]] may be made invisible to a [[Scanner#front|frontend]] by commenting out the appropriate entry in ''/etc/sane.d/dll.conf'' or ''/etc/sane.d/dll.d''.
Line 395: Line 423:
 * USB print queues previously set up with vendor drivers (HP, Brother, Canon, Samsung etc) will amost certainly [[#debian|cease to work]], so they become candidates for deletion. In fact, a user could consider removing the vendor software completely as it doesn't provide any useful function unless it is intended to switch between IPP-over-USB and vendor drivers.  * USB print queues previously set up with vendor drivers (HP, Brother, Canon, Samsung etc) will amost certainly [[#ipp-usb|cease to work]], so they become candidates for deletion. In fact, a user could consider removing the vendor software completely as it doesn't provide any useful function unless it is intended to switch between IPP-over-USB and vendor drivers.

 * Some devices have firmware bugs and are specially handled in quirk files at ''/usr/share/ipp-usb/quirks/*.conf''. The syntax used in a ''*.conf'' file is explained in the DebianMan:ipp-usb manual. Versions of ipp-usb released after the Debian 11 version additionally allow an ''/etc/ipp-usb/quirks'' directory to be created. The files for system quirks in this directory override those in the system directory.
 * A small number of devices announce the presence of [[#ippoverusb|7/1/4 interfaces]] but do not deliver IPP-over-USB support. Due to firmware bugs they [[https://github.com/OpenPrinting/ipp-usb/issues/52|fail to work]] with the protocol. From version 0.9.22 onwards, ipp-usb deals with such devices by detaching itself immediately from the USB bus to allow the USB interfaces [[#ipp-usb|to be used]] by [[PrintingGlossaryandIndex#printer|legacy/classic]] print queues and scanners.
Line 400: Line 431:
CUPS' ability [[PrintQueuesCUPS#tempq|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 (Buster), will display remote queues and IPP printers with `lpstat -e` and in the print dialogs of some applications without [[PrintQueuesCUPS#cups-browsed|cups-browsed]] (needed on Debian 8 (Jessie) and Debian 9 (stretch) 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 IPP printers that 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 [[PrintQueuesCUPS#tempq|temporary queue]].

 * `lpstat -a` shows only queues of the local CUPS daemon and not DNS-SD advertised queues or printers. `lpstat -e` and `lpstat -l -e` additionally enumerate queues and printers that can be accessed on the network.
 * The Qt print dialog of applications like DebPkg:okular and DebPkg:qpdfview enumerates remote, shared queues and printers and uses a temporary queue for printing.
CUPS' ability [[CUPSPrintQueues#tempq|directly to browse]] the DNS-SD ([[PrintingGlossaryandIndex#bonjour|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 (buster) onwaeds, will display remote queues and IPP printers with `lpstat -e` and in the print dialogs of some applications without [[CUPSPrintQueues#cups-browsed|cups-browsed]] being on the system. No action on the part of the user is required.

cups-browsed is still
needed on Debian 8 (Jessie) and Debian 9 (stretch) for remote queue management.

Essentially, CUPS itself browsing the local network uses its !CupsGetDests and !CupsEnumDests functions to discover shared queues and IPP printers that can be printed to and makes them available for display in an application and by DebianMan:lpstat. Whether or not the application displays them correvtly depends on the chosen application and the Debian distribution in use.

{{{
#! wiki important
Printing from lpstat or an application to a destination enumerated as described above leads to the formation of an [[CUPSPrintQueues#tempq|on demand, temporary queue]]. A temporary queue is intended to last for a minute only after being accessed. Its disappearence leaves the enumerated destination in existence.
}}}


 * `lpstat -a` only shows queues of the local CUPS daemon and not DNS-SD advertised queues or printers. `lpstat -e` and `lpstat -l -e` additionally enumerate queues and printers that can be accessed on the network.
 * The Qt print dialog of applications like DebPkg:okular and DebPkg:qpdfview enumerates remote, shared queues and printers.
Line 409: Line 445:

 * the GTK print dialog [[#gtk|has its own way]] of dealing with a network printer.

<<Anchor(gtk)>>
=== CUPS 2.2.4 and the GTK Print Dialog ===

The print dialog of GTK applications such as DebPkg:firefox and DebPkg:evince does not function in the same way as the [[#tempq|Qt and Libreoffice dialogs]].
It obtains queue and printer information directly from [[PrintingGlossaryandIndex#dnssd|DNS-SD]] broadcasts and not through CUPS, so it has no knowledge of what CUPS 2.2.4 and later are capable of doing.

In addition, using the GTK print dialog always results in the production of a PDF. Printers that that do not have PDF as an acceptable [[PrintingGlossaryandIndex#pdlan|PDL]] will not process such a print job.

This leads to the following problem.

 * Although the GTK dialog is aware of IPP printers on the local network via DNS-SD, it [[DebianBug:916267|does not support printing to them]] and will [[PrintQueuesCUPS#networkuri|possibly display]] a destination ''print'' and ''Rejecting Jobs'' for an IPP printer.

 * One solution is to check that [[#cupsbrowsed|cups-browsed]] is on the system and, in [[DebianMan:cups-browsed.conf|cups-browsed.conf]], have cups-browsed create permanent, local queues for remote queues and printers (rather than the CUPS [[#tempq|temporary queues]] that Qt applications and !LibreOffice use). This technique is [[#cupsbrowsed|described above]].

 * Because the GTK dialog might already show local queues and remote queues on CUPS servers it is likely that, with this first solution, only the additional entry for the remote printer is wanted. So alter ''cups-browsed.conf'' to have

{{{
CreateRemoteCUPSPrinterQueues No
}}}

 * A second solution is to create a permanent local queue for the printer with [[#lpadmin|lpadmin]], the [[#webinterface|CUPS web interface]] or [[#scp|system-config-printer]].

{{{#!wiki note
Managing queues and printers in the GTK dialog with the first solution also leads to the other dialogs adopting cups-browsed as the queue and printer management application.
}}}
 * the GTK print dialog on buster and before (DebPkg:firefox and DebPkg:evince, for example), [[CUPSPrintQueues#gtk|has its own way]] of dealing with a network printer. Unfortunately, applications that print through this dialog do not make use of CUPS' temporary queue formation. To have a queue for an IPP printer visible and usable, users should manually set up a queue with [[#shortlpadmin|lpadmin]], the [[#webinterface|CUPS web interface]] or [[#scp|system-config-printer]] or rely on cups-browsed to do it for them. The situation on bullseye and later [[CUPSPrintQueues#gtk|has improved]].

<<Anchor(dups)>>
=== Duplicate Print Queues ===

The entries shown in the print dialogs of applications are the names of existing or potential print queues. The existing queues have been set up [[#summary|manually]] or [[#summary|automatically]] with cups-browsed. A potential queue is an [[#tempq|on demand]] queue. The existing queues may also be enumerated with `lpstat -a`. Additional entries from `lpstat -e` are potential queues.

It can happen that a user observes that the print dialog contains two entries with slightly different names for the same physical printer. The two entries are often referred to as ''duplicate entries'' or ''duplicate printers''. The user expects to see only one list entry and confusion may result from being unsure which entry should be selected from the dialog list.

 * The default behaviour of the printing system is to install a queue for a [[CUPSQuickPrintQueues|network]] or [[#ipp-usb|USB]] connected printer with cups-browsed. For unknwown reasons, but possibly due to habit, the user proceeds to install a queue manually for the same printer. This results in a duplicate entry in the print dialog. It is a user-induced duplication and revealed from the output of `lpstat -a`. The solution is to let the printing system do its job and remove the manual queue or not install it in the first place.

 * A second cause of duplicate entries occurs when the [[#tempq|GTK print dialog]] is used with the default printing system and probably seen on buster. The [[PrintingGlossaryandIndex#dnssd|DNS-SD]] broadcasts of any remote print server or IPP printer are [[#tempq|directly browsed]] to produce a dialog entry. cups-browsed browses the same DNS-SD broadcasts and also populates the dialog, leading to duplicate entries. CUPS is not involved in producing the GTK dialog entry, so the solution awaits the efforts of GTK developers.

 * In normal circumstances an on demand, temporary queue entry should not appear as a duplicate entry because cups-browsed takes over the entry and creates a local queue with it. Okular, !LibreOffice and [[CUPSPrintQueues#gtk|GTK applications on bullseye]] show this behaviour. Without cups-browsed and with a manual queue, a duplicate is possible. The [[https://github.com/apple/cups/issues/5546|solution]] is to give the manual queue the same name and [[CUPSPrintQueues#deviceuri|device URI]] as the potential queue displays in `lpstat -l -e`. CUPS will then use the permanent, manual queue.

 * It is possible to use [[#ippoverusb|IPP-over-USB]] and have an ethernet or wireless connection to the printer at the the same time. There will be two entries in a print dialog. The solution is obvious!
Line 441: Line 465:
 * !AirPrint and IPP Everywhere printers generally have a [[PrintingGlossaryandIndex#ews|web interface]] for administration. It is accessed in a web browser with

{{{
http://<IP_address or host name of the printer>
 * AirPrint and [[CUPSIPPEverywhere|IPP Everywhere]] printers generally have a [[PrintingGlossaryandIndex#ews|web interface]] for administration. For an ethernet or wireless connected printer it is accessed in a web browser with

{{{
http://<IP_address or hostname of the printer>
}}}

For a USB connected printer using [[#ipp-usb|ipp-usb]] the URL is

{{{
http://localhost:60000
Line 473: Line 503:
The pdl entry for the MFC-J650DW 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 [[http://ftp.pwg.org/pub/pwg/candidates/cs-ippeveselfcert10-20160219-5100.20.pdf|self-certify]] it with the Printer Working Group (PWG). However, the presence of ''image/urf'' indicates the printer IPP implementation is sufficient for driverless printing to be used with CUPS.
The pdl entry for the MFC-J650DW has ''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 [[http://ftp.pwg.org/pub/pwg/candidates/cs-ippeveselfcert10-20160219-5100.20.pdf|self-certify]] it with the Printer Working Group (PWG). However, the presence of ''image/urf'' is a strong enough indication that the printer's IPP implementation is [[#intro|sufficient]] for driverless printing to be used with CUPS.
Line 478: Line 507:
 * Purchasing a printer with Apple raster and/or PWG raster capability means looking at the box containing the printer and printer brochures and manuals. !AirPrint has been going for some time so it is usually fairly prominent as a feature in the literature. IPP Everywhere is much newer and may not be advertised. However, PWG raster could be on a [[GoogleCloudPrint|GCP-enabled]] (GCP Ready) printer. If PDF is not a PDL for the printer it is obliged to have PWG raster. With PDF as a language it might have PWG raster as a fallback PDL.  * Purchasing a printer with Apple raster and/or PWG raster capability means looking at the box containing the printer and printer brochures and manuals. !AirPrint has been going for some time so it is usually fairly prominent as a feature in the literature. IPP Everywhere is much newer and may not be adertised.

<<Anchor(summary)>>
=== Summary ===

 * Driverless printing is available on Debian 10 (buster) and Debian 11 (bullseye) for an [[CUPSQuickPrintQueues|ethernet or wireless connected]] printer. A [[#ippoverusb|USB connected device]] is catered for on bullseye via the [[#ipp-usb|ipp-usb]] package.
 * [[DebianPkg:ipp-usb|ipp-usb]] is not provided for buster. However, its author [[https://download.opensuse.org/repositories/home:/pzz/Debian_10/|distributes a package]] that functions, provided the device is exposed to the local network by editing ''/etc/ipp-usb/ipp-usb.conf'' and having
{{{
interface = all
}}}
 * A permanent driverless print queue may be set up manually using [[#shortlpadmin|lpadmin]], the [[#webinterface|CUPS web interface]] or [[#scp|system-config-printer]]. The queue can use either [[#generator2|the cups-filters PPD generator (driverless)]] or the [[#generator1|CUPS PPD generator (everywhere)]].
 * A local driverless print queue may also be automatically set up via [[#shortcupsbrowsed|cups-browsed]]. This technique uses the cups-filters PPD generator (driverless) and is the default setup when the cups package is installed. The queue behaves no differently from one set up manually with the same PPD generator.
 * A [[#tempq|temporary driverless print queue]] using the CUPS PPD generator (everywhere) may also be automatically accessed via CUPS. The extent to which applications interact with CUPS to take advantage of this facility when cups-browsed is not active is open to investigation.
 * The [[https://github.com/OpenPrinting/cups/issues/103|future of CUPS]] does not lie with [[PrintingGlossaryandIndex#ppd|PPDs]], but, for the present, they are employed so that a traditional CUPS print queue can be driven.
 * The ability to scan on Debian 10 and 11 with an [[PrintingGlossaryandIndex#mfd|MFD]] is [[SaneOverNetwork#escl|enhanced]] by installing DebianPkg:sane-airscan.
Line 498: Line 542:
CategoryPrinter ## permalink to CUPSDriverlessPrinting#ipp-usb 2021-04 https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#driverless-operation
CategoryPermalink | CategoryPrinter

Translation(s): none


Driverless printing with CUPS. Requires at least CUPS 2.2.2 and version 1.13.0 of cups-filters. Debian 10 (buster) and later installations meet both these conditions. The advice here (an ethernet or wireless connection) and here (a USB connection) could get your modern IPP printer going with little effort.

Introduction

Driverless printing requires a modern printer. A user can be assured of having such a device when it is network-capable and it is

A Mopria-certified device calls for PWG raster, PCLm or PDF to be available as a PDL. However, it is observed that almost all PCLm, PWG raster or PDF printers also support Apple raster. Therefore, AirPrint-capability is a sufficient criterion regarding whether a printer can be operated driverlessly on Debian. Just look for AirPrint on the box or in the literature. OpenPrinting has a list of driverless printers.

It would be unusual for a network printer not to provide a USB connection too. In that case, the printer would almost certainly offer the IPP-over-USB protocol if it has been manufactured after mid-2012.

Debian 11 (bullseye) is geared up to auto-setup network and USB print queues with cups-browsed. Should auto-set fail and debugging cups-browsed is an unattactive proposition or there is a more complex situation to resolve, a manual queue setup with lpadmin, the CUPS web interface or system-config-printer is recommended.

Driverless printing for CUPS and cups-filters is here to stay. While it will be sone time before CUPS 3.0 enters a stable Debian distribution, an interested user may want to become aware of changes planned by the CUPS and cups-filters developers.

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 that 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 that 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:

  • The printer advertises its presence and capabilities with mDNS/DNS-SD (Bonjour). This is the discovery protocol; accessible printers can be identified and selected from the Bonjour broadcasts of the printer. The discovery protocol is also configured to obtain capability information from accessible printers to include in its broadcasts.

  • The client and printer communicate using the IPP protocol. This is the transport protocol; it can obtain capability information from the selected printer and transport data to it.

  • There is a common PDL that the client can send and that the printer will accept. The common PDL is based on what is obtained from the capability information for the selected printer. A driverless-enabled printer will offer at least one of Apple raster, PWG raster, PDF or PCLm as a PDL.

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.

  • Apple raster has existed for a number of years and is used with Apple's AirPrint. Unfortunately, it is not officially documented but it is known that it and PWG raster are very similar. The MIME media type is image/urf.

  • PWG raster is a more recent raster format, devised to be used with IPP Everywhere printers. It is based on CUPS raster and is well-documented. The MIME media type is image/pwg-raster.

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 appearance 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.

The CUPS PPD Generator

To support driverless printing fully, CUPS has a PPD generator that will drive a traditional CUPS print queue. The generator queries the printer and creates the necessary PPD options and values needed to support Apple Raster, PWG Raster, JPEG, and PDF printing. A CUPS generated PPD uses the everywhere model and can be identified from the *PCFileName "ippeve.ppd" line in the PPD.

  • A non-GTK application calls on CUPS to determine the filters required to convert the print file to a printer supported PDL.

  • The auto-generated PPD is consulted and a printer-ready file in the required PDL is produced.
  • The print job is submitted to the printer with the data produced from the filters.
  • If a PDF or JPEG file is being printed, it can be sent to the printer without any filtering; this is accounted for in the *cupsFilter2 lines that are added to the generated PPD.
  • A text file sent to an AirPrint or IPP Everywhere printer would often be filtered by CUPS and cups-filters to output an Apple or PWG raster file. If the printer has PDL support for MIME media type application/pdf, a PDF would be sent instead because a PDF is given the highest priority. Typical possibilities for the filter chain are:

                                     ->|--------------------------------------------> Printer
text -> texttopdf -> pdftopdf -> PDF ->| gstoraster -> rastertopwg -> PWG raster ---> Printer
                                     ->| gstoraster -> rastertopwg -> Apple raster -> Printer
  • The GTK print dialog does not use CUPS to communicate directly with IPP printers. In addition, applications using the dialog always produce a PDF to send to the printer. If this is not an acceptable PDL for the printer, printing will not take place.

The cups-filters PPD Generator

This generator uses the driverless utility and is basically a copy of the PPD generator from CUPS that has been put into the libcupsfilters library. It is kept in sync with the original by incorporating any changes to the original. A libcupsfilters generated PPD can be identified from the *PCFileName "drvless.ppd" line in the PPD.

Although the cups-filters PPD generator is kept closely in step with the CUPS one, the two are not identical:

  • The original PPD generator only supports PWG Raster, Apple Raster, PDF, and JPEG as printer PDLs. The cups-filters PPD generator also accepts (with lower priority) PostScript, PCL-XL, and PCL 5c/e for legacy printers.

  • The original PPD generator requires all printer capability, option, and choice information from the printer attributes IPP request. The cups-filters generator can, in some cases, fall back to using information from the Bonjour record or even hard-coded default values. This adds support for some legacy printers.

  • The cups-filters PPD generator is more flexible when it comes to adding support for PDLs. For example, consider PCLm: PCLm has nothing to do with PCL 5c/e and PCL-XL but is a streaming PDF-based, raster protocol (Printer Control Lanaguage-Mobile). It is mandated by the Wi-Fi Direct standard. Since version 1.17.0 of cups-filters, application/PCLm has been a supported MIME media type via the rastertopclm filter. CUPS itself will never support PCLm.

text -> texttopdf -> pdftopdf -> PDF -> gstoraster -> rastertopclm -> PCLm ---> Printer
  • cups-filters has a policy of supporting new driverless printing technologies (see above), so its PPD generator is quite likely to accomodate developments.
  • Printers have bugs in their implementation of IPP. It is more likely that the cups-filters PPD generator will produce a fix than the CUPS version of the generator.

Creating a Driverless Print Queue with lpadmin (Short Version)

Obtain the URI of a printer:

driverless

Set up the print queue (uses the CUPS PPD generator):

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

Set up the print queue (uses the cups-filters PPD generator):

lpadmin -p <print_queue_name> -v <URI> -E -m driverless:<URI>

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 /usr/sbin/lpinfo -v could be:

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

The snmp backend has found the printer will accept jobs on port 9100 (socket://192...). CUPS will not set up an everywhere queue using this URI because it is unable to query the printer with it.

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-filters 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.

It may be preferred to have the PPD generated by cups-filters, so first find the driver URI (driverless:ipp://...) with

driverless list

and create the queue with

lpadmin -p <print_queue_name> -v <device-uri> -E -m <driver URI>

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.

  • Open the web interface and choose Administration. Select Add Printer.

  • Your printer will be under the Discovered network Printers:, probably with more than one entry. Choose the entry that contains the word driverless and move on to Continue.

  • Check that Connection is ipp://... and continue to the next page.

  • Under Model there should be options of IPP Everywhere and driverless, cups-filters. The first option uses the CUPS PPD generator and the second the cups-filters PPD generator. Select and activate Add Printer.

Creating a Driverless Print Queue with system-config-printer

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

  • Start system-config-printer and choose Add followed by Network Printer.

  • Highlight the printer entry and choose the Driverless IPP entry.

  • Moving on has system-config-printer searching for a driver, auto-generating a PPD with the cups-filters generator and offering a screen to describe the printer. Choose Apply when done.

  • system-config-printer cannot use the CUPS PPD generator.

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

Edit /etc/cups/cups-browsed.conf to uncomment the directive below:

CreateIPPPrinterQueues All

Restart cups-browsed:

systemctl restart cups-browsed

cups-browsed version 1.27.1 changed the default for CreateIPPPrinterQueues to All. Considering that cups-browsed is a recommended package for cups-daemon, this change should lead to making IPP printers immediately visible and available on a bullseye installation.

Creating a Driverless Print Queue with cups-browsed

This method leads to discovery of an AirPrint or IPP Everywhere printer and the automatic set up of a print queue with lpadmin. A PPD for the queue is created using the cups-filters PPD generator. The CUPS PPD generator may be used instead; see the UseCUPSGeneratedPPDs directive in the cups-browsed.conf manual. 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:

  • Edit /etc/cups/cups-browsed.conf to set the CreateIPPPrinterQueues to All or Driverless and restart cups-browsed.

CreateIPPPrinterQueues All
CreateIPPPrinterQueues Driverless

systemctl restart cups-browsed

cups-browsed version 1.27.1 changed the default for CreateIPPPrinterQueues to All. Considering that cups-browsed is a recommended package for cups-daemon, this change should lead to making IPP printers immediately visible and available on a bullseye installation.

  • Check the existence of the queue and its options with

lpstat -t
lpoptions -p <queue_name> -l
  • The device-uri should begin ipp://.... The queue name is got from lpstat -t.

  • The queue persists provided the printer is switched on and cups-browsed is running.
  • With the CreateIPPPrinterQueues directive cups-browsed sets up a queue for a remote printer. With NewIPPPrinterQueuesShared Yes in /etc/cups/cups-browsed uncommented the printer is shared with other machines on the local network.

  • cups-browsed supports also a kind of legacy driverless printing. This means that some other common PDLs such as PostScript, PCL-XL, and PCL 5c/e are supported and also older IPP versions (1.x). Note that missing capability information can be replaced with default values and that implementations of these languages in the printers are often not reliable, so that, in contrast to official driverless printing, printing often does not work perfectly. Note that the PCL of HP inkjets does not work and therefore cups-browsed does not auto-create queues for this PDL.

IPP-over-USB: The Basics

The previous methods to set up driverless printing with CUPS are presented in the context of a network-only connection (wireless or ethernet). They require the Internet Printing Protocol (IPP) for querying the capabilities of 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 exactly the same way via USB using the IPP-over-USB daemon, ipp-usb. ipp-usb serves for using the device via USB; this is fully independent of whether there is also a network connection available between the computer and the printer. A recent AirPrint printer should support IPP-over-USB. The support situation regarding USB-only post-2012 printers has yet to be completely clarified, but it is known that such devices are not guaranteed to understand the protocol.

The IPP USB specification describes an extension to USB that defines a standard for making IPP available over a USB Print class interface, and is intended to allow USB connected devices to achieve functional parity with network connected devices using IPP. In other words, whatever can be done over a network connection may also be done over a USB connection. A USB connected printer is therefore seen as a network printer when IPP-over-USB is used.

The previous sentence indicates that users employing the CUPS web interface or system-config-printer should be looking under network printers to establish a connection with the printer.See SystemPrinting for more detail.

It should be straightforward and reliable to use a printer or multi-function device via ethernet or WiFi and, in general, there are advantages to this type of connection. Some reasons why a user may want or have a preference for a USB connected MFD or printer are:

  • A local network does not exist and Wi-Fi Direct is not offered by the device.

  • The local network is regarded as operating unreliably.
  • The computer is USB-only.
  • The MFD or printer is USB-only.
  • The user sees setting up a network connection as an extra complication to avoid.
  • The MFD or printer is rarely used. When it is, it is simpler and easier just to plug it into a USB port.
  • The user values having a USB connection as a fallback method for printing.
  • Sending confidential documents via USB is mandated as being more secure than sending them over a network.

Whether a printer can use IPP-over-USB may be determined by executing lsusb -v|less and searching for the lines containing bInterfaceClass.*7. A bInterfaceProtocol line should be found a few lines below each bInterfaceClass line. Look for bInterfaceProtocol 4.

Alternatively, execute lsusb -v | grep -A 3 bInterfaceClass.*7

A value of 4 for bInterfaceProtocol indicates a USB IPP device:

bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
bInterfaceProtocol 4
iInterface 0

The interface is usually referred to as being a 7/1/4 one.

IPP-over-USB: Automatic Discovery and Setup

Beginning with version 2.3.3-2 the cups-daemon package installs ipp-usb as a recommended package. When an IPP-over-USB device is connected to the computer, systemd will use /lib/systemd/system/ipp-usb.service to start the daemon. cups-browsed is also installed by default, so, because the USB connected printer emulates a network printer, it will auto-create a driverless print queue for the printer.

  • The result is that the USB connected printer becomes immediately available for printing to. Nothing else need be done. Manually setting up a driverless print queue is also an option.

Note that IPP-over-USB reserves the USB interface connection with the printer/scanner exclusively for itself and communication with a printer/scanner device by software that does not operate using the IPP-over-USB protocol becomes impossible while ipp-usb is running. This is a consequence of the design of USB communication. It is not a bug in ipp-usb.

  • For example, a print queue for an HP MFD can be set up with a vendor driver and PPD, but printing to it will not take place because the software does not use the IPP-over-USB protocol. The same holds true for all other drivers, free or non-free. Only driverless print queues will work with IPP-over-USB. It would be as well to remove existing queues based on vendor drivers to avoid the appearance of non-working queues in print dialogs. Removing vendor packages (free or non-free) from the system is also something to consider.

Communicating with a USB connected scanner via classic SANE backends such as libsane-hpaio, sane-pixma or sane-epson2 also becomes impossible with the ipp-usb daemon active and running.

  • Expecting the non-free Brother and Samsung backends to work would also be unreasonable. Only driverless backends will work with IPP-over-USB. A good solution to have reliable scanning with IPP is to install the independent SANE backend, sane-airscan, in addition to the official SANE backend,sane-escl, that comes with libsane1. sane-airscan is a highly regarded backend that interworks with IPP-over-USB very well. A non-working SANE backend may be made invisible to a frontend by commenting out the appropriate entry in /etc/sane.d/dll.conf or /etc/sane.d/dll.d.

An important idea underlying IPP-over-USB is having the ability to expose the local USB-connected printer only to localhost and not to the entire local network. This condition is fulfilled by using at least version 0.8-1 of avahi-daemon.

  • If it is desired to share the printer on the local network or with iOS and Android devices, alter the interface parameter in /etc/ipp-usb/ipp-usb.conf to all.

IPP-over-USB: Investigation and Troubleshooting

Remember, although the actual physical connection is a USB one, the device has effectively become a networked device advertised on localhost by default, not to the local network. All the usual network commands may be used in addition to the CUPS commands.

  • Determine the state of ipp-usb:

systemctl list-units "ipp-usb*" | grep service
systemctl status ipp-usb

  • A portion of a typical output from avahi-browse -rt _ipp._tcp is shown below. Note that the DNS-SD advertisment is on localhost. The port used is not 631 because this is claimed by cups-daemon. ipp-usb takes the printer's DNS-SD name (usually configurable via the printer's web interface and often known as the Bonjour name), adds a space followed by (USB) as a suffix to it and uses the resulting string for announcing the printer. The port number is incremented when additional printers are attached to the USB bus. avahi-browse is in the avahi-utils package.

=     lo IPv4 ENVY4500 (USB)  Internet Printer        local
hostname = [desktop.local]
address = [127.0.0.1]
port = [60000]
  • Access the printer's EWS for administrative tasks via a browser:

http://127.0.0.1:60000
http://desktop.local:60000

  • If cups-browsed is not on the system or it hasn't generated a print queue, not even after re-plugging the printer, a user has the option of creating a driverless print queue using the CUPS web interface, system-config-printer or lpadmin. But keep in mind that the IPP-over-USB printer is seen as a network device and be sure always to look under network printers with both of these setup solutions. Ignore the temptation to set up a local USB connection even though the device is on USB. Under the model/driver entries look for entries containing driverless or IPP Everywhere.

  • Obtain a URI for the printer by executing:

driverless

lpadmin -p <chosen_printer_name> -v <URI> -m everywhere
lpadmin -p <chosen_printer_name> -v <URI> -m driverless:<URI>
  • lpstat -l -e shows all available destinations on the local network. ENVY4500_USB_ is the queue name or destination created by CUPS for an IPP-over-USB printer. It is formed from what ipp-usb sees as the printer's DNS-SD name. ENVY4500 (USB). ipp://ENVY4500... is the URI of the printer. Having permanent instead of network indicates a destination that has been auto-setup by cups-browsed or installed with lpadmin, the CUPS web interface or system-config-printer.

ENVY4500_USB_ network none ipp://ENVY4500%20(USB)._ipp._tcp.local/
envy4500usb permanent ipp://localhost/printers/envy4500usb ipp://ENVY4500%20(USB)._ipp._tcp.local/
  • List the printer or print queue specific options and their current settings. These options should also be presented in the print dialog of an application:

lpoptions -p <destination> -l

  • USB print queues previously set up with vendor drivers (HP, Brother, Canon, Samsung etc) will amost certainly cease to work, so they become candidates for deletion. In fact, a user could consider removing the vendor software completely as it doesn't provide any useful function unless it is intended to switch between IPP-over-USB and vendor drivers.

  • Some devices have firmware bugs and are specially handled in quirk files at /usr/share/ipp-usb/quirks/*.conf. The syntax used in a *.conf file is explained in the ipp-usb manual. Versions of ipp-usb released after the Debian 11 version additionally allow an /etc/ipp-usb/quirks directory to be created. The files for system quirks in this directory override those in the system directory.

  • A small number of devices announce the presence of 7/1/4 interfaces but do not deliver IPP-over-USB support. Due to firmware bugs they fail to work with the protocol. From version 0.9.22 onwards, ipp-usb deals with such devices by detaching itself immediately from the USB bus to allow the USB interfaces to be used by legacy/classic print queues and scanners.

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 (buster) onwaeds, will display remote queues and IPP printers with lpstat -e and in the print dialogs of some applications without cups-browsed being on the system. No action on the part of the user is required.

cups-browsed is still needed on Debian 8 (Jessie) and Debian 9 (stretch) for remote queue management.

Essentially, CUPS itself browsing the local network uses its CupsGetDests and CupsEnumDests functions to discover shared queues and IPP printers that can be printed to and makes them available for display in an application and by lpstat. Whether or not the application displays them correvtly depends on the chosen application and the Debian distribution in use.

Printing from lpstat or an application to a destination enumerated as described above leads to the formation of an on demand, temporary queue. A temporary queue is intended to last for a minute only after being accessed. Its disappearence leaves the enumerated destination in existence.

  • lpstat -a only shows queues of the local CUPS daemon and not DNS-SD advertised queues or printers. lpstat -e and lpstat -l -e additionally enumerate queues and printers that can be accessed on the network.

  • The Qt print dialog of applications like okular and qpdfview enumerates remote, shared queues and printers.

  • The libreoffice print dialog behaves the same way as the Qt dialog.

  • the GTK print dialog on buster and before (firefox and evince, for example), has its own way of dealing with a network printer. Unfortunately, applications that print through this dialog do not make use of CUPS' temporary queue formation. To have a queue for an IPP printer visible and usable, users should manually set up a queue with lpadmin, the CUPS web interface or system-config-printer or rely on cups-browsed to do it for them. The situation on bullseye and later has improved.

Duplicate Print Queues

The entries shown in the print dialogs of applications are the names of existing or potential print queues. The existing queues have been set up manually or automatically with cups-browsed. A potential queue is an on demand queue. The existing queues may also be enumerated with lpstat -a. Additional entries from lpstat -e are potential queues.

It can happen that a user observes that the print dialog contains two entries with slightly different names for the same physical printer. The two entries are often referred to as duplicate entries or duplicate printers. The user expects to see only one list entry and confusion may result from being unsure which entry should be selected from the dialog list.

  • The default behaviour of the printing system is to install a queue for a network or USB connected printer with cups-browsed. For unknwown reasons, but possibly due to habit, the user proceeds to install a queue manually for the same printer. This results in a duplicate entry in the print dialog. It is a user-induced duplication and revealed from the output of lpstat -a. The solution is to let the printing system do its job and remove the manual queue or not install it in the first place.

  • A second cause of duplicate entries occurs when the GTK print dialog is used with the default printing system and probably seen on buster. The DNS-SD broadcasts of any remote print server or IPP printer are directly browsed to produce a dialog entry. cups-browsed browses the same DNS-SD broadcasts and also populates the dialog, leading to duplicate entries. CUPS is not involved in producing the GTK dialog entry, so the solution awaits the efforts of GTK developers.

  • In normal circumstances an on demand, temporary queue entry should not appear as a duplicate entry because cups-browsed takes over the entry and creates a local queue with it. Okular, LibreOffice and GTK applications on bullseye show this behaviour. Without cups-browsed and with a manual queue, a duplicate is possible. The solution is to give the manual queue the same name and device URI as the potential queue displays in lpstat -l -e. CUPS will then use the permanent, manual queue.

  • It is possible to use IPP-over-USB and have an ethernet or wireless connection to the printer at the the same time. There will be two entries in a print dialog. The solution is obvious!

CUPS and Driverless Printing: Miscellaneous

http://<IP_address or hostname of the printer>

For a USB connected printer using ipp-usb the URL is

http://localhost:60000

The hostname can be obtained from the output of avahi-browse (see below). Make sure that IPP support and Bonjour broadcasting on the printer 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.

avahi-browse -rt _ipp._tcp

Bonjour-advertised IPP printers are now identified. 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:

URF=CP1,MT1-2-8-9-10-11,OB9,OFU0,PQ3-4-5,RS300-600,SRGB24,W8-16,DEVW8-16,DEVRGB24-48,ADOBERGB24-48,DM3,IS1,V1.3
pdl=application/vnd.hp-PCL,image/jpeg,application/PCLm,image/urf

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/vnd.brother-hbp,image/pwg-raster,image/urf,image/jpeg

The pdl entry for the MFC-J650DW has 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, the presence of image/urf is a strong enough indication that the printer's IPP implementation is sufficient for driverless printing to be used with CUPS.

  • Driverless printing usually allows only adjustments on printing as they are thought out by the printer manufacturers. A printer driver like Gutenprint allows a lot fine tuning that goes far beyond a manufacturer's possibilities. This driver may suit photo enthusiasts more than a driverless solution. Having said that, the quality of text or images printed with rastertopwg is yet to be challenged.

  • Purchasing a printer with Apple raster and/or PWG raster capability means looking at the box containing the printer and printer brochures and manuals. AirPrint has been going for some time so it is usually fairly prominent as a feature in the literature. IPP Everywhere is much newer and may not be adertised.

Summary

interface = all

Acknowledgements

Didier 'OdyX' Raboud <odyx@debian.org> for guiding and supporting CUPS 2.2.2, cups-filters and cups-browsed through the experimental archive and into unstable; also for packaging ipp-usb and sane-airscan; Till Kamppeter <till.kamppeter@gmail.com> for his integration of cups-filters and cups-browsed with CUPS 2.2.2; also for producing a patch to allow IPP-over-USB to work on localhost with Avahi and encouraging Trent Lloyd <trent.lloyd@canonical.com> to apply it. Michael R. Sweet <msweet@apple.com> for developing the rastertopwg filter to support Apple raster. Alexander Pevzner <pzz@apevzner.com> for the creation of ipp-usb and sane-airscan.

See Also


CategoryPermalink | CategoryPrinter