[RFE] Check for driverless support and set device-info accordingly

[zdohnal]

Hi,

I encountered this problem several times during debugging printing issues with older printers - the device is capable to advertise itself via Avahi but its IPP response is not enough for CUPS temporary queue, either if it does not support IPP 2.0 or it's missing some required attributes.

Fortunately those printers can be driverless with help of cups-browsed, which has those two fallbacks available so even older IPP printers can be supported as driverless.

The problem is when you run 'sudo lpinfo -l -v', driverless backend says 'driverless' in device-info text - but it indicates only the device is available on avahi-browse, because driverless backend calls ippfind tool for the job and it just checks Avahi.
So you don't know (until you try to install it with 'everywhere' model) if the device is capable of being CUPS temporary queue or if cups-browsed is needed for working.

The patch is about propagation of info which fallback was used during get-printer-attributes request (called during running driverless backend) and it sets the part of device-info string about driverless to one of following 4 strings:

1. 'driverless - cannot check driverless status' - when get-printer-attributes fails
2. 'fully driverless' - device supports IPP standard ippeve
3. 'driverless via IPP1.1' - device supports IPP 1.1 get-printer-attributes
4. 'driverless with incomplete IPP request' - device supports get-printer-attributes without media-col-database

I tested it with my fully driverless HP LaserJet and with Canon printer of my colleague, which has incomplete IPP request. I wrote a basic sanity test for driverless backend in the past and it passes too.

What do you think about it? Is it a usable for the project? Please let me know if I should change something.

Thank you in advance!

[tillkamppeter]

Thank you very much for your patch, I have merged it. Some remarks:

1. cups-browsed is only needed for fully automatic setup of printers which are not 100% driverless-compatible (IPP 1.1 or no media-col-database), manual driverless setup is possible thanks to the driverless utility, simply choose the "driverless" entries under the network printers in system-config-printer.
2. The PPD NickName is displayed by the output of driverless differently than it appears in the PPD file. It should not do any harm to the printer setup process, but I am not 100% sure. Did you test creating print queues with the help of driverless, especially also with system-config-printer (should skip the make/model/driver step and automatically choose a PPD provided by driverless).

[zdohnal]

Thank you very much for your patch, I have merged it. Some remarks:

Thank you for merging it @tillkamppeter !

1. cups-browsed is only needed for fully automatic setup of printers which are not 100% driverless-compatible (IPP 1.1 or no media-col-database),

Or if you want to have 'permanent' queue for IPP everywhere supported device being installed automatically (without g-c-c or s-c-p), which is sometimes needed when you need to print via GTK print dialog in certain network setups.
E.G. my home network has a router to which the printer is connected, but all devices are in the same subnet, so it is available via Avahi. But I'm not able to use CUPS temporary queue to print in evince/firefox/any gtk application, so I need to either add the printer manually or run cups-browsed.

I'm working on more generic solution (hopefully using CUPS API) in gtk in https://bugzilla.redhat.com/show_bug.cgi?id=1784449 with Marek Kasik, who is in gtk upstream.

manual driverless setup is possible thanks to the driverless utility, simply choose the "driverless" entries under the network printers in system-config-printer.

To be honest, I always use 'lpadmin' with 'everywhere' model, so I hit the issue when printer does not support IPP everywhere as whole. Thanks for the tip about model 'driverless:' for lpadmin!

2. The PPD NickName is displayed by the output of `driverless` differently than it appears in the PPD file. It should not do any harm to the printer setup process, but I am not 100% sure. Did you test creating print queues with the help of `driverless`, especially also with system-config-printer (should skip the make/model/driver step and automatically choose a PPD provided by `driverless`).

I did not test it with GUI apps yesterday, but today I did - it works correctly. Do you want to propagate the info into a created PPD too? I can update the patch.

[tillkamppeter]

I did not test it with GUI apps yesterday, but today I did - it works correctly. Do you want to propagate the info into a created PPD too? I can update the patch.

Not really needed. Important is that it actually works.

[tillkamppeter]

Note that there is also work in progress on support for the Common print Dialog Backends (CPDB) in the GTK print dialog, the CPDB (exactly the CUPS backend) also support temporary CUPS queues.

[tillkamppeter]

Removed this feature again (master: 3fddcf5; 1.x: aae86d2), as the check takes too long time, making CUPS failing. See OpenPrinting/cups#65.