This one is bug 184798 item D)

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
YaST printer module should be prepared to deal with
the conflict if it is not solved until 10.2