"hp" CUPS backend should report the real IEEE-1284 device IDs, not artificial ones

I have problem with this patch because it is not backward compatable with older distros. The patch adds libudev as a new dependency which is certainly not used by most distros yet.

Can you be more specific about the problem with the current "hp" backend? Can you give me an printer example?

We have named all our PPDs to match USB/DeviceID model names including the PS PPDs. So this should be an easy case insensitive match.

There are also other solutions that I prefer over this patch.

1. With CUPS 1.4 the "usb" backend is libusb compatible. I can modify the "hp" backend to provide real device-ids without using libudev or usblp.

2. I have talked to Mike Sweet about adding manufacturer extensions to the "usb" backend. Mike talked about doing this for CUPS 1.4. Then we could merge the "hp" backend into the "usb" backend.

-dave

The libudev dependency is not necessarily needed. udev is used here only to poll the device ID if the libusb method fails, for example if the usblp module is in the way. With this we want to avoid to detach the printer from the module before the user sets up a queue for it (and perhaps opts for the CUPS "usb" backend). I attach a simple C program which polls the devioce ID through usblp without use of libudev. This code can be used as fallback code if a libusb-based poll fails. Perhaps failure of the libusb-based poll is even impossible (I am not such a USB expert), then no usblp fallback is needed.

Also compile-time conditionals could be added.

The problem is the following:

The HP Color LaserJet CM3530 MFP has the device ID

MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PCLXL,PCL,PDF,PJL,POSTSCRIPT;MDL:HP Color LaserJet CM3530 MFP;CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CM3530 MFP;

See especially the manufacturer name field which is "Hewlett-Packard". The artificial device ID puts "HP" here.

Same for the LaserJet 1020 and 3390.

This means that printer setup tools (and also our udev callout) have to deal with matching different device ID fields in the readout from the printer and the device IDs reported by each CUPS backend. It is much easier if the IDs are simply the same.

We would at least need to replace "Hewlett-Packard" by "HP" and do case-insensitive comparing. But imagine if many manufacturers require their exceptions in the printer setup tools.

I am looking forward to the day when the "hp" backend is not needed any more for USB printers. How will it work then with network printers. Will the "socket" backend also get manufacturer extensions?

I can fix the "MFG:" field with USB enumeration. I can simply use the USB "iManufacturer" descriptor which specifies "HP" or "Hewlett-Packard". This will match the deviceID.

> I am looking forward to the day when the "hp" backend is not
> needed any
> more for USB printers. How will it work then with network
> printers. Will
> the "socket" backend also get manufacturer extensions?

Good point. URIs for ip, mdns and scanning would require some thought...

-dave

How about the serial number (i.e. "SN:...")?

Incidentally, Till, you made a mistake porting that patch to 3.9.6b:

+ if (fd == FD_NA)

that should read

+ if (fd == FD_MAX)

Tim, when I do this change HPLIP does not build any more:

libtool: compile: gcc "-DPACKAGE_NAME=\"HP Linux Imaging and Printing\"" -DPACKAGE_TARNAME=\"hplip\" -DPACKAGE_VERSION=\"3.9.6b\" "-DPACKAGE_STRING=\"HP Linux Imaging and Printing 3.9.6b\"" -DPACKAGE_BUGREPORT=\"3.9.6b.4\" -DPACKAGE=\"hplip\" -DVERSION=\"3.9.6b\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_PTHREAD_H=1 -DHAVE_JPEGLIB_H=1 -DHAVE_UINT32_T=1 -DHAVE_LIBHPIP=1 -DHAVE_PPORT=1 -DHAVE_LIBCRYPTO=1 -DHAVE_LIBNETSNMP=1 -DHAVE_NET_SNMP_NET_SNMP_CONFIG_H=1 -DHAVE_LINUX_PPDEV_H=1 -DHAVE_CUPS_CUPS_H=1 -DHAVE_USB_H=1 -DHAVE_PYTHON2_6_PYTHON_H=1 -DHAVE_DBUS=1 -I. -Iip -Iio/hpmud -Iscan/sane -DMUDNAME=\"hpmud\" -DCONFDIR=\"/etc/hp\" -Wall -pipe -g -O2 -c io/hpmud/musb.c -fPIC -DPIC -o .libs/libhpmud_la-musb.o
io/hpmud/musb.c: In function ‘get_device_id’:
io/hpmud/musb.c:1983: error: ‘FD_MAX’ undeclared (first use in this function)
io/hpmud/musb.c:1983: error: (Each undeclared identifier is reported only once
io/hpmud/musb.c:1983: error: for each function it appears in.)
io/hpmud/musb.c:2013: warning: unused variable ‘idProduct’
make[1]: *** [libhpmud_la-musb.lo] Error 1
make[1]: Leaving directory `/home/till/ubuntu/hplip/svn/pkg-hpijs/build-area/hplip-3.9.6b'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1334:
dpkg-buildpackage -rfakeroot -D -us -uc failed
Command /bin/sh -c debuild "-rfakeroot" failed in /home/till/ubuntu/hplip/svn/pkg-hpijs/build-area/hplip-3.9.6b, how to continue now? [Qri?]: ^C

Tim, now I see. It must be MAX_FD and not FD_MAX.

But can't we eliminate the use of udev for the usblp-based ID poll. CUPS does it alo without udev. If needed I can attach 10 lines of code for a udev-free ID poll.

Here is a little C program which polls the device ID via usblp kernel module:

http://www.openprinting.org/download/printing/usb_id_test.c

It does not use udev.

If the hp backend can guarantee that the Device ID it reports will have exactly matching MFG, MDL and SERN fields with the actual device, that's all we need.

"CUPS does it also without udev" -- CUPS, of course, fails to report any devices at all if built with libusb support and usblp is loaded...

I wrote the libudev routine for the hp backend just as one possible way to resolve the problem. If the HPLIP maintainers have a simpler solution, so much the better...

Yes, the "SR:" number in the generated deviceID is valid.

For HP products the USB "iSerialNumber" and "iManufacturer" descriptors are the same as the deviceID "SR:" and "MFG:" fields. There should be no reason to read deviceID at udev event time because all the device discovery info is in the USB enumeration.

-dave

Dave, can you then generate the reported device ID based on "iSerialNumber" and "iManufacturer" in 3.9.8, so that printer setup tools can easily compare the device IDs? Thanks in advance.

Yes, its already in the tip for the 3.9.8 release...

Dave,

unfortunately, your solution has a bug. See the output of the "hp" backend below (typical desktop configuration of 9 printers on the USB of one computer). For some of the printers (LaserJet 1020, LaserJet 3390, Color LaserJet CM3530 MFP) the MFG field is filled with the serial number and not with the manufacturer name.

till@till-laptop:~/ubuntu/hplip/test/hplip-3.9.8$ /usr/lib/cups/backend/hp
direct hp:/usb/Photosmart_A710_series?serial=CN6B92118304R4 "HP Photosmart A710 series" "HP Photosmart A710 series USB CN6B92118304R4 HPLIP" "MFG:HP;MDL:Photosmart A710 series;CLS:PRINTER;DES:Photosmart A710 series;SN:CN6B92118304R4;"
direct hp:/usb/HP_LaserJet_1020?serial=JL377QZ "HP LaserJet 1020" "HP Hewlett-Packard USB LaserJet 1020 HPLIP" "MFG:JL377QZ;MDL:HP LaserJet 1020;CLS:PRINTER;DES:HP LaserJet 1020;SN:JL377QZ;"
direct hp:/usb/psc_1200_series?serial=BR44H4G02T5H "HP psc 1200 series" "HP psc 1200 series USB BR44H4G02T5H HPLIP" "MFG:Hewlett-Packard;MDL:psc 1200 series;CLS:PRINTER;DES:psc 1200 series;SN:BR44H4G02T5H;"
direct hp:/usb/Photosmart_Pro_B9100_series?serial=MY7143104604C1 "HP Photosmart Pro B9100 series" "HP Photosmart Pro B9100 series USB MY7143104604C1 HPLIP" "MFG:HP;MDL:Photosmart Pro B9100 series;CLS:PRINTER;DES:Photosmart Pro B9100 series;SN:MY7143104604C1;"
direct hp:/usb/HP_Color_LaserJet_CM3530_MFP?serial=CNFND01964 "HP Color LaserJet CM3530 MFP" "HP Hewlett-Packard USB Color LaserJet CM3530 MFP HPLIP" "MFG:CNFND01964;MDL:HP Color LaserJet CM3530 MFP;CLS:PRINTER;DES:HP Color LaserJet CM3530 MFP;SN:CNFND01964;"
direct hp:/usb/Photosmart_C8100_series?serial=MY7B5F70P704YH "HP Photosmart C8100 series" "HP Photosmart C8100 series USB MY7B5F70P704YH HPLIP" "MFG:HP;MDL:Photosmart C8100 series;CLS:PRINTER;DES:Photosmart C8100 series;SN:MY7B5F70P704YH;"
direct hp:/usb/HP_LaserJet_3390?serial=00CNMJP81545 "HP LaserJet 3390" "HP Hewlett-Packard USB LaserJet 3390 HPLIP" "MFG:00CNMJP81545;MDL:HP LaserJet 3390;CLS:PRINTER;DES:HP LaserJet 3390;SN:00CNMJP81545;"
direct hp:/usb/Photosmart_C5200_series?serial=MY7C3FD0XZ0559 "HP Photosmart C5200 series" "HP Photosmart C5200 series USB MY7C3FD0XZ0559 HPLIP" "MFG:HP;MDL:Photosmart C5200 series;CLS:PRINTER;DES:Photosmart C5200 series;SN:MY7C3FD0XZ0559;"
direct hp:/usb/Officejet_H470?serial=CN7BU18154 "HP Officejet H470" "HP Officejet H470 USB CN7BU18154 HPLIP" "MFG:HP;MDL:Officejet H470;CLS:PRINTER;DES:Officejet H470;SN:CN7BU18154;"
till@till-laptop:~/ubuntu/hplip/test/hplip-3.9.8$

The attached patch fixes the problem.

Argh, good catch...

I have tested the fix now and the udev callouts of system-config-printer work with it. The problem is fixed. Thanks, Dave.

Doesn't work here with HPLIP-3.9.8 and an HP DeskJet 990C. The reason is that the device ID fields are different. They differ in case:

The actual MFG field is "HEWLETT-PACKARD".
The actual MDL field is "DESKJET 990C".

The reported MFG field is "Hewlett-Packard".
The reported MDL field is "DeskJet 990C".

When I said usb enumeration would match device-id I really ment case insensitive match. This should not be a problem with newer hp printers.

Tim, in system-config-printer I do all comparing of manufacturer, model, serial number, device ID, ... case-insensitive. You should also do it case-insensitive in udev-configure-printer and udev-add-printer.

I can do that, it's just a bit annoying that it's necessary. Oh well.