When creating a print queue via command line, I cannot auto-select the driver

[tillkamppeter]

I want to create a queue via command line manually (not "autoadd", so that I can choose the queue name and also create a queue for a network printer) but I want to auto-select the driver, therefore I use -m auto:

$ ./ps-printer-app add -d usbtest2 -v 'usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1' -m auto -o log-level=debug
ps-printer-app: Unable to add printer - Driver 'auto' cannot be used with this printer.
$

The queue does not get created as "auto" is not accepted as driver name. I get this result also if I use the network connection of the printer, by supplying the SNMP- or DNS-SD-based URI instead of the USB device URI.

The debug logging of the server is

I [2021-02-21T21:07:03.559Z] [Client 25] Accepted connection from 'localhost'.
I [2021-02-21T21:07:03.560Z] [Client 25] POST http://localhost:0/ipp/system HTTP/1.1
I [2021-02-21T21:07:03.560Z] [Client 25] Continue
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request: IPP/2.0 request-id=1
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request: operation-attributes-tag
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   attributes-charset charset utf-8
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   attributes-natural-language naturalLanguage en-us
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   system-uri uri ipp://localhost/ipp/system
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   printer-service-type keyword print
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request: printer-attributes-tag
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   printer-name nameWithoutLanguage usbtest2
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   smi2699-device-command keyword auto
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer request:   smi2699-device-uri uri usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter(system=0x55ec73711070, resource="(null)", printer_id=0, device_uri="(null)")
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'test' - resource="/ipp/print/test", printer_id=1, device_uri="dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C09108C229%5C093._pdl-datastream._tcp.local/"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'test2' - resource="/ipp/print/test2", printer_id=2, device_uri="dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C09108C229%5C093._pdl-datastream._tcp.local/"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'usbtest' - resource="/ipp/print/usbtest", printer_id=3, device_uri="usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: Returning (nil)(none)
D [2021-02-21T21:07:03.560Z] [Client 25] IPP/2.0 Create-Printer (CUPS/2.3.3op2 (Linux 5.10.0-13-generic; x86_64) IPP/2.0)
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter(system=0x55ec73711070, resource="/ipp/print/usbtest2", printer_id=0, device_uri="(null)")
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'test' - resource="/ipp/print/test", printer_id=1, device_uri="dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C09108C229%5C093._pdl-datastream._tcp.local/"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'test2' - resource="/ipp/print/test2", printer_id=2, device_uri="dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C09108C229%5C093._pdl-datastream._tcp.local/"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: printer 'usbtest' - resource="/ipp/print/usbtest", printer_id=3, device_uri="usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1"
D [2021-02-21T21:07:03.560Z] papplSystemFindPrinter: Returning (nil)(none)
I [2021-02-21T21:07:03.560Z] Printer 'usbtest2' at resource path '/ipp/print/usbtest2'.
I [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer client-error-attributes-or-values-not-supported (Driver \'auto\' cannot be used with this printer.)
I [2021-02-21T21:07:03.560Z] [Client 25] OK application/ipp 173
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response: IPP/2.0 request-id=1, status-code=client-error-attributes-or-values-not-supported
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response: operation-attributes-tag
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response:   attributes-charset charset utf-8
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response:   attributes-natural-language naturalLanguage en-us
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response:   status-message textWithoutLanguage Driver \'auto\' cannot be used with this printer.
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response: unsupported-attributes-tag
D [2021-02-21T21:07:03.560Z] [Client 25] Create-Printer response:   smi2699-device-command keyword auto
I [2021-02-21T21:07:03.560Z] [Client 25] Closing connection from 'localhost'.

[tillkamppeter]

Note that ./ps-printer-app autoadd and also creating a queue with auto-selecting the driver via the web interface work as expected.

[tillkamppeter]

This is especially important to get fixed as we need this for simple tools to guide users to set up their printer with a Printer Application. The tool could list printers available (on USB, non-IPP-2.x on network) and if the user selects one to set up he can get a menu of installed Printer Applications, the user chooses one and then the tool has to do PRINTER_APPLICATION -d NAME -v URI -m auto and in case that the printer is supported by the Printer Application this should result in a print queue with the driver auto-selected within the Printer Application.

see also the discussion about automatic printer setup on the OpenPrinting mailing list, thread "Automatic printer setup with Printer Applications".

[michaelrsweet]

@tillkamppeter You're going to have to be patient, I'm in the middle of integrating my IPP-USB gadget code and that trumps any bug fixing at the moment...

[michaelrsweet]

@tillkamppeter Can you verify whether your ps_autoadd callback is getting called? Everything appears to be plumbed correctly to allow this to work, so papplPrinterCreate should be calling your callback to get the actual driver name. If it gets NULL or it doesn't think there is an auto-add callback then things won't work.

[tillkamppeter]

I have found what the problem is:

If the driver name "auto" is used, the autoadd_cb is called. The autoadd_cb() of the PostScript Printer Application (and in the future also of many other Printer Applications) requires the device ID to know which make and model the printer is. It immediately exits with NULL if the device ID is NULL.

The server calls the function ipp_create_printer() as response to the client's IPP request for adding a printer. This function is supposed to get the device ID via the "printer-device-id" IPP attribute:

  if ((attr = ippFindAttribute(client->request, "printer-device-id", IPP_TAG_ZERO)) != NULL && (ippGetGroupTag(attr) != IPP_TAG_PRINTER || ippGetValueTag(attr) != IPP_TAG_TEXT || ippGetCount(attr) != 1))
  {
    papplClientRespondIPPUnsupported(client, attr);
    return;
  }
  else
    device_id = ippGetString(attr, 0, NULL);

The client, using the function _papplMainloopAddPrinter() does not supply this attribute, but the server does not error on this attribute missing. In case attr being NULL in the code abobe, the else part is executed setting device_id to NULL.

The actual bug is that the device ID is nowhere polled from the printer. Polling the device ID is required for auto-determination of the driver. In addition, ipp_create_printer() should give a decent error message if the driver is "auto" and no device ID is supplied.

[tillkamppeter]

An additional hint for the best possible fix:

Let the device ID be polled by the server, as in case of the Printer Application being a Snap, the server runs as root and the client runs as normal user (Issue #148) and with this the chances to obtain the device ID are much higher for the server.

[michaelrsweet]

@tillkamppeter I will see about adding a 1284 query, but for 1.0 (at least) that will only work for USB printers because the code to try to query the 1284 ID for a network printer isn't hooked up - SNMP is unreliable at best and not all printers advertise the 1284 keys in the DNS-SD TXT record.

[tillkamppeter]

In DNS-SD, if there is no device ID in the TXT record (can there be the complete one at all?) then next step is usb_mfg, usb_mdl, and usb_cmd for an artificial, but good enough device ID (which gives full functionality in the autoadd_cb() of the PostScript Printer Application and will work as well with any future Printer Application). If usb_mfg and or usb_mdl are myssing, needed info can get taken from ty and product, id usb_cmd is missing an artificial CMD: field can be constructed from pdls. So in DNS-SD one should always get enough info to supply a useful device ID.

So both USB and DNS-SD should not be a problem, SNMP will sometimes work sometimes not.

[michaelrsweet]

[master b1e9e6e] Fix auto driver without 1284 device ID (Issue #154)

[v1.0.x 5d6ccb2] Fix auto driver without 1284 device ID (Issue #154)

[michaelrsweet]

@tillkamppeter Please let me know about this issue and #153 so I can put out the 1.0.3 release. Thanks!

[tillkamppeter]

OK, with my printer connected via USB it works now.

It does not work with SNMP or DNS-SD URIs, will probably still need the appropriate device-specific backing for the papplDeviceGetID() function, in case of DNS-SD as I suggested here.

Issue #153 is a problem of my printer as I have found out. I have no other printer for testing.

So I am fine with 1.0.3 release.

[michaelrsweet]

@tillkamppeter WRT DNS-SD, all you have are usb_CMD, usb_MFG, and usb_MDL in the TXT record to build the 1284 device ID. You can also try parsing out the product (PostScript product string), ty (make and model), and pdl (MIME media types) keys - PAPPL does all of these things to generate a 1284 ID when listing devices. The issue is that currently the network schemes do not currently support a later lookup of these values like the USB scheme does. Tracking that with issue #95...