USB printers: Blacklist for CUPS "usb" backend when supported by hplip "hp" backend

[Till Kamppeter]

If HPLIP which its "hp" backend is installed, each USB printer supported by "hp" gets detected twice by CUPS, once via "hp" and once via CUPS' original "usb" backend. See also the output of the "lpinfo -v" command. This can confuse users as printer setup tools show each printer twice and users do not know which instance to select. Note that most users simply use the system's printer setup tool and not hp-setup.

From CUPS 1.7.1 on the CUPS "usb" backend can apply special treatment to printers specified in external files. This is mainly intended for printers which are in some way not compatible to the "usb" backend but as one special treatment is total blacklisting, one can make the original backend ignore printers when a better backend for these printers is present.

Implementing this is very easy: The better backend, in our case "hp" of the HPLIP package gets shipped with a blacklist file, so that whenever "hp" is installed also the blacklist file is installed and so the printers supported by "hp" get only detected by "hp" and not by the original backend as there they are blacklisted. If one uninstalls HPLIP, both the backend and the blacklist file get uninstalled and the printers are all detected by the original backend again.

The blacklist file has to be placed in the /usr/share/cups/usb/ directory with the suggested name com.hplipopensource.usb-quirks and for each printer supported by the "hp" backend it should contain a line like

0x04a9 0x304a blacklist

with the first hex number being the USB vendor ID and the second being the USB product ID. The file can also contain blank lines and everything after a "#" is considered a comment and ignored. 0x0000 as product ID makes all printers of the manufacturer given by the vendor ID being blacklisted, but be careful, there can be HP printers not being supported by the "hp" backend.

The "usb" backend silently ignores all printers blacklisted this way, in your case ending up that your printers are only detected via the "hp" backend.

Can you add such a file to HPLIP, to make setting up HP's USB printers easier for the user?

[Till Kamppeter (till-kamppeter)]

You do not need to worry about the installed CUPS version when installing the file, if CUPS is too old, it simply ignores the file and all behaves as before.

[Johannes Meixner (jsmeix)]

I would appreciate it very much if HP implemented that.

I like to propose a possible enhancement:

Instead of one single file /usr/share/cups/usb/com.hplipopensource.usb-quirks
that lists all HPLIP supported devices I suggest to split them into three files
as follows:

/usr/share/cups/usb/com.hplipopensource.mandatory.usb-quirks
that lists those HPLIP supported devices that cannot work
with the generic "usb" backend from CUPS

/usr/share/cups/usb/com.hplipopensource.recommended.usb-quirks
that list all HPLIP supported all-in-one devices

/usr/share/cups/usb/com.hplipopensource.optional.usb-quirks
that list all HPLIP supported plain printer devices that
also work with the generic "usb" backend from CUPS

This way the Linux distributor's printer setup tools
(like system-config-printer, yast2-printer, ...)
could implement support to distinguish what backends
get offered to the user depending on to what extent
the generic "usb" backend from CUPS can also be used.

Additionally experienced users or business admins could easily
decide which backends are available to be used for HP devices
by installing or removing whole files (instead of editing particular
entries in one huge file).

Finally the Linux distributors could install
/usr/share/cups/usb/com.hplipopensource.mandatory.usb-quirks
in any case (e.g. add it to their CUPS packages) so that
devices that cannot work with the generic "usb" backend from CUPS
are not listed by the generic "usb" backend from CUPS
regardless if HPLIP is installed or not.

Till,
right now I got an idea for a possible enhancement
for the blacklisting functionality:

Do you think it is possible that the generic "usb" backend from CUPS
could show an information message when it detects a printer
that cannot work with "usb" so that the user knows HPLIP must be installed?

I have something like the following in mind:

CUPS contains a special kind of
/usr/share/cups/usb/com.hplipopensource.mandatory.usb-quirks
so that the generic "usb" backend from CUPS shows no DeviceURI
but only something like "HPLIP must be installed to use this device".

HPLIP contains its own
/usr/share/cups/usb/com.hplipopensource.mandatory.usb-quirks
that "somehow overwrites" the default one from CUPS
so that when HPLIP is installed, the generic "usb" backend from CUPS
gets totally silent and only "hp" reports the devices.

When HPLIP gets uninstalled, the default one from CUPS
should somehow become re-activated again.

I know this could become tricky (e.g. with RPM) but currently
I only like to descibe the basic idea behind what should happen.

Till,
do you think the basic idea makes sense?

[Till Kamppeter (till-kamppeter)]

I think this with giving an output line without Device URI and a comment would make sense, one could add an additional quirk type, like having this line in a quirk file

0x1234 0x5678 comment HP LaserJet 9999 needs HPLIP installed to work on USB

giving a line like this in "lpinfo -v"

direct usb HP LaserJet 9999 needs HPLIP installed to work on USB

It must be tested whether it does not break existing printer setup tools and probably support for this must be added to the current printer setup tools.

Even better would be having a machine-readable package name in the output to download from the distro or from OpenPrinting.

[Johannes Meixner (jsmeix)]

I did a quick test (with CUPS 1.5.4):

I made /usr/lib/cups/backend/myusb
to simulate such device discovery information:
-----------------------------------------------------------------------------
#! /bin/bash
# Output "device discovery" information on stdout:
if test "$#" = "0"
then echo 'direct usb "HP LaserJet 9999" "HP LaserJet 9999 needs HPLIP installed to work on USB"'
fi
exit 0
-----------------------------------------------------------------------------

Accordingly I get
-----------------------------------------------------------------------------
# lpinfo -l -v | grep -2 9999
Device: uri = usb
        class = direct
        info = HP LaserJet 9999 needs HPLIP installed to work on USB
        make-and-model = HP LaserJet 9999
        device-id =
        location =
-----------------------------------------------------------------------------

Now it depends on what "not break existing printer setup tools"
should mean.

The above device discovery information is valid
according to "man 7 backend" and therefore it cannot
break existing printer setup tools that work in compliance
with CUPS.

But lpadmin fails (I use CUPS 1.5.4):
-----------------------------------------------------------------------------
# lpadmin -p testy -v usb -E
lpadmin: Bad device-uri "usb".

# echo $?
1
-----------------------------------------------------------------------------

I think it is perfectly right that lpadmin and all
printer setup tools that work in compliance with CUPS
fail to set up a print queue because such a print queue
cannot work and accordingly the user should get
a failure error message when he did not notice the
"HP LaserJet 9999 needs HPLIP installed to work on USB"
information or when a printer setup tool does not show
the backend's device-info output.

Currently the YaST2 printer setup tool does intentionally
not show device discovery information when no device-uri
but only the scheme was ouptut by a backend
(i.e. only "usb" instead of "usb:/...").

I described the reason in this comment in the
YaST2 printer setup tool sources:
-----------------------------------------------------------------------------
// do a special filtering for those connections which are supposed to work
// i.e. where the uri seems to be a complete DeviceURI e.g. "socket://192.168.1.2:9100"
// and not just an URI scheme like a plain "socket".
-----------------------------------------------------------------------------

The root cause is that lpadmin fails (at least up to CUPS 1.5.4)
when only the scheme but no real device-uri is provided:
-----------------------------------------------------------------------------
# lpinfo -v | grep -v :
network smb
network http
network ipp
network ipps
network lpd
direct usb
direct pipe
direct hal
network https
network beh
network socket
direct hp
direct hpfax

# for s in $( lpinfo -v | grep -v : | cut -d ' ' -f2 ) ; \
 do lpadmin -p testy -v $s -E ; echo $? ; done
lpadmin: Bad device-uri "smb".
1
lpadmin: Bad device-uri "http".
1
lpadmin: Bad device-uri "ipp".
1
lpadmin: Bad device-uri "ipps".
1
lpadmin: Bad device-uri "lpd".
1
lpadmin: Bad device-uri "usb".
1
lpadmin: Bad device-uri "hal".
1
lpadmin: Bad device-uri "pipe"...

[Johannes Meixner (jsmeix)]

Regarding a machine-readable package name
in the device discovery information output:

According to "man 7 backend" (in CUPS 1.5.4)
the only possible form of device discovery information
when only the backend scheme (e.g. "usb") is output is
-----------------------------------------------------------------------------
device-class scheme "Unknown" "device-info"
-----------------------------------------------------------------------------

Therefore the device discovery information in my above commnet
'direct usb "HP LaserJet 9999" "HP LaserJet 9999 needs HPLIP installed to work on USB"'
is not in compliance to "man 7 backend" and should be
'direct usb "Unknown" "HP LaserJet 9999 needs HPLIP installed to work on USB"'

This means only "device-info" can be used to somehow
encode a machine-readable package name therein.

I think we should discuss with Michael Sweet what he thinks about it.

Should I send a mail to <email address hidden>
or may I submit it as an STR at cups.org?

[Till Kamppeter (till-kamppeter)]

Johannes, perhaps you start on <email address hidden> as you get more readers there. Then, after having some discussion perhaps, you post the STR.