[cups.bugs] [MOD] STR #3860: When updating a system from using usblp and the usblp-based usb backend to blacklisting usblp and using the libusb-based backends USB device URIs change incompatibly

[Till Kamppeter]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Following some e-mail exchange with Mike Sweet I have deprecated the usblp
kernel module in Ubuntu and Debian, at least if CUPS is used as the
printing system.

In the Debian/Ubuntu package of CUPS I have switched over from getting the
usblp kernel module auto-loaded and using the usblp-based "usb" CUPS
backend to blacklisting the usblp kernel module and using the libusb-based
"usb" CUPS backend.

For my 8 HP printers on USB I formerly got the URIs as follows:

----------
usb://HP/Color%20LaserJet%20CM3530%20MFP?serial=CNFND01964
usb://HP/LaserJet%203390?serial=00CNMJP81545
usb://HP/Officejet%20H470?serial=CN7BU18154
usb://HP/Photosmart%20A710%20series?serial=CN6B92118304R4
usb://HP/Photosmart%20C5200%20series?serial=MY7C3FD0XZ0559
usb://HP/Photosmart%20C8100%20series?serial=MY7B5F70P704YH
usb://HP/Photosmart%20Pro%20B9100%20series?serial=MY7143104604C1
usb://HP/psc%201200%20series?serial=BR44H4G02T5H
----------

and after the switchover to libusb-based USB printer access I get

----------
usb://HP/HP%20Color%20LaserJet%20CM3530%20MFP?serial=CNFND01964
usb://HP/HP%20LaserJet%201020?serial=JL377QZ
usb://HP/HP%20LaserJet%203390?serial=00CNMJP81545
usb://HP/Officejet%20H470?serial=CN7BU18154
usb://HP/Photosmart%20A710%20series?serial=CN6B92118304R4
usb://HP/Photosmart%20C5200%20series?serial=MY7C3FD0XZ0559&interface=1
usb://HP/Photosmart%20C8100%20series?serial=MY7B5F70P704YH&interface=1
usb://HP/Photosmart%20Pro%20B9100%20series?serial=MY7143104604C1
usb://HP/psc%201200%20series?serial=BR44H4G02T5H&interface=1
----------

There are four problems leading to differences. Two of the problems are
visible in my sample of HP printers. Attached is a patch which solves
these problems. Here are the problems:

1. If the MDL field of the device ID contains the manufacturer name, the
usblp-based backend removes the manufacturer name, so that it is not
repeated in the URI, the libusb-based backend does not do so. Probably the
needed piece of code got simply forgotten. This is addressed by the first
hunk of the patch. See the URIs for the HP Color LaserJet CM 3530 MFP and
for the HP LaserJet 3390 in my sample URIs.

2. The usblp-based backend could add the expression "serial=?" at the end
of the URI, the libusb backend never does this. The patch (second hunk)
makes the libusb-based backend considering URIs with "serial=?" equal to
URIs without "serial" parameter, so that print queues with such an old URI
simply keep working.

3. The libusb-based backend does not exclusively obtain the serial number
through device IDs but also via raw USB. So there are cases where the URI
from the usblp-based backend has no serial number but the URI from the
libusb backend has. If a queue with an old URI from the usblp-based
backend has no serial number, the libusb-based backend matches it with any
URI for this printer, also with an arbitrary serial number. A warning in
error_log is issued in such a case that for connecting more than one
printers of this model, the old URI needs to be updated. This is also in
the second hunk of the patch. Unfortunately, I have no printer which gives
an example of this case.

4. The libusb-based backend supports USB printers with more than one USB
interface and so it produces URIs with "interface=..." added. These are
also incompatible with the usblp-backend-provided URIs which do never have
this extension. Also here we let a queue with an URI without
"interface=..." match any libusb-discovered URI with "interface=..." and
we also warn in error_log. In the example above, the URIs for the HP
PhotoSmart C5200, the HP PhotoSmart C8100, and the HP PSC 1200 show this
difference.

This makes printing with USB printers continue to work out of the box when
one migrates from the usblp kernel module to libusb-based access and for
all users for which the usblp-based access worked perfectly, the
libusb-based access will work the same way. Only users who want to use the
new features of the libusb-based backend (two printers of the same model on
one machine if the serial number is not in the device ID, using the
additional interfaces of a multi-interface printer) need to regenerate the
URIs of their old print queues. This assures an out-of-the-box printing
experience as far as possible.

Link: http://www.cups.org/str.php?L3860
Version: 1.4-current
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb-backend-accept-old-usblp-uris.dpatch
Type: application/octet-stream
Size: 3626 bytes
Desc: not available
URL: <https://lists.cups.org/pipermail/cups/attachments/20110610/2de95875/attachment.obj>