Is driverless a driver?

[debiantriage]

I set up

lpadmin -p testq -v URI -E -m driverless:URI

I get

Printer drivers are deprecated and will stop working in a future version of CUPS

My understanding is that driverless is not a driver: https://lists.linuxfoundation.org/pipermail/printing-architecture/2021/004048.html

Will this fit with an eventual CUPS 3.0 or is it too soon to say?

[tillkamppeter]

A driver is device-model-specific software or data. Driverless operation eliminates the need of any such information on a client system which wants to use the device. Usually this is implemented by the device using standardized communication protocols and the client know to use them. If the client needs device-specific information, the device has it available for the client querying it.

For driverless printing this means that the printer is advertising itself via DNS-SD, the client discovers it and queries its properties by IPP, then sending jobs via standard PDLs (Page Description Languages) PWG Raster, Apple Raster (URF), PCLm, PDF.

The software for this is not model-specific, so it is not a driver.

The problem here is that current CUPS (< 3.0) only supports printing with a driver (usually consisting of a PPD file containing the printer's properties and a filter converting a standard PDL to the printer's PDL), raw (no filtering at all, throwing the incoming job data directly to the printer), and driverless printing only in two very restricted ways, which are not easy to deal with with typical client applications (applications which want to print).

One method of driverless printing are temporary CUPS queues. If there is a driverless-capable printer in the local network (or a Printer Application which is a software emulation of such a printer) CUPS discovers it by DNS-SD and knows about it, but does not auto-create a print queue right away, but instead, it only creates a queue if a client's request cannot be responded without a queue, either a get-printer-attributes IPP request to query full capabilities, and equivalent CUPS API request, a request to download the PPD file, or, simply a job. After processing the request and one minute of inactivity CUPS removes the queue again.

The concept is nice as you do not need to create CUPS queues any more, instead you set up network printers and/or install Printer Applications.

The problem is that print dialogs use an obsolete API which does not see possible temporary queues, making all GUI projects using the correct API would make live much easier, but there is a lot of inertia and long release cycles in GUI toolkit development. So we need permanent queue. One way which CUPS provides is lpadmin ... -m everywhere ... but this is implemented in lpadmin so rather awkward to use, especially also not having something which makes it done automatically (Note: A recent commit in CUPS moves the implementation of the everywhere model name into cupsd which makes it available for all methods of print queue setup).

Therefore I have added two workarounds into cups-filters. One is cups-browsed which fully automatically creates local permanent queues for all discovered printers.

The other, the driverless utility retro-fits driverless printing into pseudo drivers, to make it accessible in printer setup tools like system-config-printer or the web interface of CUPS itself. It makes use of CUPS' way how it copes with (non-driverless) printers for decades. Backends in /usr/lib/cups/backend discover the devices, by CUPS running all of them in turn without arguments, PPD generators (Michael calls them "driver"??) in /usr/lib/cups/driver are executables called in turn with the list argument when CUPS searches for all available PPD files. They list the PPDs they are capable to generate when called with cat.

driverless is linked into /usr/lib/cups/backend and /usr/lib/cups/driver and plays both roles, ending up with the printer setup tool listing the driverless IPP printers and marking them as such and when it comes to find a driver for them, listing the the PPD files which driverless auto-generates by doing a get-printer-attributes IPP request. CUPS even auto-assigns these PPDs to these printers in its web interface. As CUPS only sees the answers of driverless and does not know its internals, it is simply another printer driver for CUPS (CUPS also does not very well understand English) and so it happily gives its deprecation warning, but as it is a warning and not an error and deprecation is not immediate removal it is no problem for now.

But tI have always succeeded to let the show go on seamlessly for the users, whatever feature Michael (or anyone else) is removing by throwing in workarounds and retro-fits quickly enough, before running into a pandemic-alike "I CANNOT PRINT!!!" crisis.

Next up is retro-fitting all classic CUPS drivers into Printer Applications (PostScript already works, and note that PostScript is not driverless, the PPDs are device-model-specific), as CUPS 3.x will (most probably) drop PPD support, meaning that only temporary queues will be available and so drivers only work by emulating driverless IPP printers, Printer Applications ...

[debiantriage]

Thank you for the level of detail. I'll describe the context of my query.

I have a printer application, ippeveprinter, set up:

/usr/sbin/ippeveprinter -f application/pdf ippeveprinter

Its URI was obtained with driverless and a queue created: lpadmin -p testq -v tea4cups:/URI -m everywhere, which reports

Unable to connect to ":0": Name or service not known

lpadmin -p testq -v tea4cups:/URI -E -m driverless:URI succeds and data reaches a Tea4CUPS hook when printing to testq. The data are in PDF format (from pdftopdf) but that should be OK to manipulate.

This is encouraging as it seems to indicate that the Tea4CUPS backend can survive changes in CUPS and be adapted to them.

[debiantriage]

The problem is that print dialogs use an obsolete API which does not see possible temporary queues, making all GUI projects using the correct API would make live much easier, but there is a lot of inertia and long release cycles in GUI toolkit development. So we need permanent queue. One way which CUPS provides is lpadmin ... -m everywhere ... but this is implemented in lpadmin so rather awkward to use, especially also not having something which makes it done automatically

IMHO, all the print dialogs need to up their games.

• A permanent queue is, AFAICT, the only way to get reliable printing from GTK apps.
• Qt apps and LibreOffice enumerate a CUPS temporary queue but do not offer all the queue attributes (two-sided printing and print quality, for example).
• Without cups-browsed one wonders whether users would be easily able to see queues displayed and take full advantage of them!

[tillkamppeter]

Note that with -m everywhere CUPS is getting the IPP URI of the printer from the device URI. This fails with the tea4cups-extended device URI. If you use driverless you supply the IPP URI separately in the -m argument where driverless finds and uses it. This way you get a correct PPD for the queue independent what the device URI is.

This way driverless helps you when printing driverless with third-party CUPS backends.

[tillkamppeter]

@dryairship, @rithvikp1998: Any progress on the CPDB integration in the GTK and Qt print dialogs?

[mwilck]

Therefore I have added two workarounds into cups-filters. One is cups-browsed which fully automatically creates local permanent queues for all discovered printers.

Does this suppress the creation of the temporary queues by CUPS?

[tillkamppeter]

@mwilck not completely, but if there is a permanent CUPS queue with a certain URI CUPS will not create a temporary queue with the same URI. So if cups-browsed creates permanent queues for all the IPP printers it finds in the local network, there is no printer left for which CUPS would create a temporary queue.

[mwilck]

Thanks!

[zdohnal]

IMHO, all the print dialogs need to up their games.

* A permanent queue is, AFAICT, the only way to get reliable printing from GTK apps.

Hi Brian,

what gtk3 version do you use? GTK provides basic temp queues support since 3.24.25. Debian Sid has 3.24.24 and only Debian experimental has a gtk version providing temp queue support (3.24.29). GTK now uses CUPS_CREATE_LOCAL_PRINTER operation as Libreoffice does, so it's a start.

It would be great if we tested the latest GTK properly, gathered issues which are in the current implementation and they could be fixed by using CPDB. This output would give us arguments for communication with GTK developers about CPDB. gtk 3.24.25 is already in Ubuntu Hirsuite, so the testing can happen in Ubuntu as well.

[debiantriage]

Hello Zdenek,

Thanks for the heads-up. I use Debian sid and rarely install from experimental. But I did try GTK 3.24.29. There are good improvements in it, so I have learnt something.

My ENVY 4500 now displays attributes as they appear in lpoptions -p envy4500 -l, including Duplex and Print Quality. That is better than LibreOffice or Qt apps do.

That was with the printer on the network. On USB (with ipp-usb) the behaviour of the print dialog was similar but there were a few issues. For example, getting

Rejecting jobs

was not unknown. Things are looking up! Not there yet. More testing.

[debiantriage]

I submitted https://gitlab.gnome.org/GNOME/gtk/-/issues/4106

[debiantriage]

Note that with -m everywhere CUPS is getting the IPP URI of the printer from the device URI. This fails with the tea4cups-extended device URI.

I thought that to be the case. In other words, the printer could not be queried. Anyway I did ask at OpenPrinting/cups and eventually wrote this.

I appreciate Tea4CUPS is a minority sport but I feel you would not want it to disappear from the Printing Olympics!

[tillkamppeter]

@debiantriage I also ran in the problem of the "Rejecting Jobs" by the GTK dialog for temporary queues on local services (IPP-over-USB or Printer Application). I have found a solution for it in CUPS, correcting the network hostname to "localhost" when creating the temporary queue. See Pull request #353. I have applied this patch also to the CUPS package in Ubuntu 22.04 LTS (Jammy Jellyfish).