HP Deskjet 5150 shows up as an HP Deskjet 5100 in various places

Hey Aurelio - I've subscribe you to this bug, since you also mentioned the problem in your bug report, bug 65568.

Chris Burgan - I don't believe this bug is in gnome-cups-manager. I just downloaded the source to that package, and it does not seem to contain a list of printers...

I'll go ahead and set this bug against the "hplip" package, to see if I can get any input from someone more knowledgeable...

There are two methods to ask a printer to identify itself:

1. lsusb

2. The IEEE-1284 device ID, on USB requested via IOCTLs, see the following simple programs

http://www.linuxprinting.org/download/printing/usb_id_test.c
http://www.linuxprinting.org/download/printing/getusbprinterid.pl

both to be called with "<program name> /dev/usblp0".

The second method is also available for parallel printers, use

cat /proc/sys/dev/parport/parport*/autoprobe*

to obtain the device IDs for the printer(s) on the parallel port(s).

Unfortunately, the firmware of some printers is not consistent and gives two different results with the different methods.

lsusb sometimes does not give manufacturer/model info at all whereas the device ID always gives manufacturer/model info and if the device IDs of two printers are equal, they accept exactly the same info and therefore work with the same driver and PPD. Therefore, when using only one of the two methods it is more reliable to assign the correct driver to a printer when polling the device ID.

The numerical vendor/product IDs, which lsusb reads out are completely unsuitable for printers, as for example nearly all Epson printers have the same vendor/product IDs. Therefore I switched the printer detection from vendor/product IDs to the IEEE-1284 device ID in Mandriva Linux (printerdrake) years ago.

CUPS and HPLIP use IEEE-1284 device IDs and modern Linux distributions usually detect printers through CUPS (and this triggers also detection through HPLIP, due to HPLIP's CUPS backend "hp").

In your case of HP printers every HP printer is sold in different flavours for different markets. The hardware of a series of printers is equal, but they come with different Windows toys or different input voltages. HP gives similar model names, like DeskJet 5100 and DeskJet 5160. The IEEE-1284 device IDs are the same in such a case (for example "DeskJet 5100 series").

The problem is only cosmetic, as all printers of such a series work with the same driver. So your 5150 will work without problems.

The only solution for this bug report would be to probe every detected printer also with "lsusb" and if there is manufacturer/model info use this only for the menu/list entry and use the IEEE-1284 device ID only for selecting the correct PPD/driver. Or one simply adds a text like the following to the auto-detection results list in the printer setup tools:

Note: Printers do not necessarily identify themselves with the model name as specified on the printer's case, but the precision of the self identification is sufficient for selecting the correct driver.

Till, thank you for the excellent detail about this issue. Sorry I
didn't respond sooner.

I tried to use the Perl script, below, but had no luck:
  chris@chris-desktop:~/Desktop$ sudo perl
getusbprinterid.pl /dev/usblp0
  Died at getusbprinterid.pl line 3.
  chris@chris-desktop:~/Desktop$ sudo perl
getusbprinterid.pl /dev/bus/usb/002/003
  Died at getusbprinterid.pl line 12.

I'm not sure if /dev/bus/usb/002/003 is the right device node. `lsusb`
shows a line like
  Bus 002 Device 003: ID 03f0:6204 Hewlett-Packard DeskJet 5150c
so I assumed the 002/003 corresponded to the Bus/Device listed there.

/dev/usblp* doesn't exist at all on my system.

Any thoughts? Thank you.

> I tried to use the Perl script, below, but had no luck

You can use the following command from foo2zjs package, installed by default on Ubuntu Edgy/Feisty:
$ sudo usb_printerid /dev/usblp0

> /dev/usblp* doesn't exist at all on my system.
Can you follow the steps described here: https://wiki.ubuntu.com/DebuggingPrintingProblems, please attach the output of the printingbug info script.

> You can use the following command from foo2zjs package, installed by default on Ubuntu Edgy/Feisty:
> $ sudo usb_printerid /dev/usblp0

Like I said, no such /dev/usblp* devices exist on my system. I've attached the output of the printingbuginfo script.

You do not have /dev/usblp0 as HPLIP uncouples your printer from the Linux kernel (and /dev/usblp0 is a kernel feature). So you can poll the printer's device ID only via HPLIP. To do so, enter

lpinfo -l -m

to make CUPS searching for printers. CUPS also asks HPLIP and so you will get an entry like

Device: uri = hp:/usb/HP_LaserJet_3390?serial=00CNMJP81545
        class = direct
        info = HP LaserJet 3390 USB 00CNMJP81545 HPLIP
        make-and-model = HP LaserJet 3390
        device-id = MFG:HP;MDL:HP LaserJet 3390;CLS:PRINTER;DES:HP LaserJet 3390;SN:00CNMJP81545;

somewhere in the output which contains the printer's device ID in the last line.

Or run

hp-info

select your printer and you find a line with the device ID in the output.

To get the device ID from the kernel using the programs mentioned in earlier comments in this bug report do

sudo /etc/init.d/hplip stop
sudo rmmod usblp
sudo modprobe usblp

to recouple the printer to the kernel, then do

sudo getusbprinterid.pl /dev/usblp0

to see the ID and

sudo /etc/init.d/hplip start

to restart HPLIP that you can print again.

Added the idea of warning users about the reported model name and the real model name being different in some cases to the printerdrake blueprint:

https://blueprints.launchpad.net/ubuntu/+spec/printerdrake

See the improvement ideas in the "Design"section on the Wiki page of the blueprint:

https://wiki.ubuntu.com/PrinterDrake

On Thu, 2007-05-24 at 19:45 +0000, Till Kamppeter wrote:
> Added the idea of warning users about the reported model name and the
> real model name being different in some cases to the printerdrake
> blueprint:
>
> https://blueprints.launchpad.net/ubuntu/+spec/printerdrake

Thanks Till. That satisfies me (not that I was too terribly worried
about this issue, but...).