This is an enhancement request for Suse Linux 10.2.
Nevertheless it is marked as "major" bug because
at the moment the HPLIP support in YaST printer module
is insufficient for the current HPLIP version (i.e. if nothing
changes in YaST it would be actually a major bug in 10.2).
For RPMs of the current HPLIP for Suse Linux 10.1, see
ftp://ftp.suse.com/pub/people/jsmeix/unsupported/hplip/10.1/RPMS/

This one is intended as a summary what should be done to get
"full HPLIP support in YaST printer module".


A)
The topmost problem is that YaST hides the special case "HPLIP"
from the user (e.g. it doesn't show the correct CUPS DeviceURI
but instead some vague "beautified" information so that it
is not clear whether the CUPS "usb" backend is used or the
HPLIP "hp" backend).

For a normal user (i.e. a user who doesn't know about what
is going on behind the YaST surface) the HPLIP stuff is
obscure and as a result it results easily wrong setups.

See the related bug #175323.

To solve it, I suggest the following:
Seperate HPLIP printers from usual USB/parport/network printers.
Therefore add a new connection type for HPLIP printers, see
https://bugzilla.novell.com/show_bug.cgi?id=175323#c9

Which models belong to HPLIP is listed in
/usr/share/hplip/data/xml/models.xml
YaST should parse this file instead of the currently used
fixed list of HP all-in-one devices because only this file
matches always to the actually installed version of HPLIP.
Hopefully the model names in the "case-model" section
match well to the autodetected model name.


B)
Support HPLIP network printers and all-in-one devices.
See netx item C):


C)
Add support for faxing in YaST.
This is a real enhancement request.

The current HPLIP supports sending faxes for HP all-in-one devices
if the device has a built-in fax-unit.
I have a HP Officejet 7210 with USB and network connection to test it.
Michal, do you also have a HP all-in-one device with built-in fax-unit?

To send a fax an additional special print queue must be set up
(therefore it belongs to the YaST printer module).
This queue must use the new special backend "hpfax"
(/usr/lib[64]/cups/backend/hpfax)
and it must use the new special PPD file "HP-Fax-hplip.ppd"
(/usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax-hplip.ppd).
The DeviceURI for the "hpfax" queue is the same as for the
normal "hp" print queue only the backend name is exchanged, e.g.:
When the DeviceURI for the HPLIP print queue is
hp:/usb/Officejet_7200_series?serial=1X2Y3Z
then the DeviceURI for the HPLIP fax queue is
hpfax:/usb/Officejet_7200_series?serial=1X2Y3Z

Remember that HPLIP also supports network printers.
For example my Officejet 7210 has the IP address 10.10.100.100
and my DeviceURIs are
hp:/net/Officejet_7200_series?ip=10.10.100.100
hpfax:/net/Officejet_7200_series?ip=10.10.100.100

To autodetect a HPLIP network printer, the user must specify its IP.
(The "hp" backend does no network scan.)
Then the HP tool /usr/share/hplip/makeuri can be used:
----------------------------------------------------------------------
user@host$ /usr/share/hplip/makeuri -c -s -f 10.10.100.100
hp:/net/Officejet_7200_series?ip=10.10.100.100
hpaio:/net/Officejet_7200_series?ip=10.10.100.100
hpfax:/net/Officejet_7200_series?ip=10.10.100.100
----------------------------------------------------------------------
See "/usr/share/hplip/makeuri -h".

Which models do have a built-in fax-unit is listed in
/usr/share/hplip/data/xml/models.xml
(i.e. all models where "fax type" != "0")
see the comments at the bottom of this file.


D)
usblp <-> usbfs/libusb conflict:

The current HPLIP "hp" backend removes HP USB-printers
from the USB device list (it uses libusb) so that the CUPS
usb backend will no longer work with those printers.
Remember that during startup of cupsd all backends are executed
so that at the moment no HP USB-printer works with the
CUPS usb backend if HPLIP is installed.
According to the HPLIP developers this will change the future:
-------------------------------------------------------------------------
Suffield, David wrote (shortened):
> > I have fixed this in the "hp" backend for the next release. 
> > A device discovery in the "hp" backend will no longer remove
> > the usblp for that URI. But, any other I/O (ie: printing,
> > toolbox or scanning) will remove usblp for that URI which
> > would disable the "usb" backend for that URI.
> 
> Could you explain why the "usb" backend and the "hp" backend 
> can no longer co-exist for "real" I/O?
> 
> When they cannot co-exist for "real" I/O, there will be the 
> problem that a queue can be set up using "usb" because it can 
> detect the printer and a second queue for the same device can 
> be set up using "hp" because it also detects the device but 
> then the "usb"-queue stops to work as soon as the "hp"-queue 
> was used once.

[...]

Yes, this is a general kernel problem. You cannot have two different
drivers (kernel modules) talking to the same USB device. In this case
usblp and usbfs (ie: libusb). 

I have talked to Michael Sweet, and he is planning on releasing a
libusb version of the CUPS "usb" backend. Once both backends
use libusb the problem goes away.
-------------------------------------------------------------------------

Regardless what there will be in Suse Linux 10.2:
The crucial point is that YaST printer module must work
in full compliance to the CUPS backend design and in
full compliance to the HPLIP design - otherwise
it may too often end up for the user in obsure mess.

Regarding disabled queues remember bug 119588.