Comment 3 for bug 405804

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?