Bug 175555 - system-config printer should use hplip for HP PSC devices
system-config printer should use hplip for HP PSC devices
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: hal-cups-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: FutureFeature
Depends On: 175758
Blocks: FC6Update
  Show dependency treegraph
 
Reported: 2005-12-12 14:02 EST by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.6.5-1.fc6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-18 13:17:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2005-12-12 14:02:17 EST
HP PSC devices require hplip to be installed and system-config-printer should
then prefer / only show the hplip way to get to this device, this way scanning
works too (out of the box). A problem is that hplip doesnot seem to get
installed by default, maybe system-config-printer should depend on this?
Comment 1 Tim Waugh 2005-12-13 04:54:09 EST
I don't think that system-config-printer ought to depend on hplip, since there
are very many use-cases that don't require it and it is quite large.

We should add it to comps, though, wherever cups appears.
Comment 2 Hans de Goede 2005-12-13 06:42:29 EST
Sounds reasonable, as long as it gets installed by default. Also
system-config-printer should use and if nescesarry enable hplip for PSC (all in
one) devices if installed. When using hplip one can just startup xsane and
everything works.

I can get it to work myself, but we want tobe as much plug and play as possbile,
right?
Comment 3 Tim Waugh 2005-12-13 09:33:53 EST
That aspect is much harder to fix, as printconf-tui creates the queues that
kudzu/cups-config-daemon tell it to.
Comment 4 Hans de Goede 2005-12-14 02:54:43 EST
Should I file a bug against kudzu for this then?

My mother in law has such a printer and I have converted here over to Linux, no
for other mother in law scenarios it would be nice if this would work 100% out
of the box, and all the parts are there.
Comment 5 Tim Waugh 2005-12-14 05:04:07 EST
Yes please -- against hal I think.
Comment 6 Jesse Keating 2005-12-14 12:20:43 EST
Assigning it to hal.
Comment 8 John (J5) Palmieri 2006-01-11 14:58:26 EST
This is a foomatics issue isn't it?
Comment 9 John (J5) Palmieri 2006-01-11 15:01:48 EST
I should be cleared.  We just tell cups-config-printer what make and model and
printconf then looks up that make and model in foomatics and sets up the queue
with that info.  If foomatics points to the hplip drivers that is what it uses.
Comment 10 Hans de Goede 2006-01-11 15:29:01 EST
The problem is not the selected driver, the problem is that with hplip installed
and the daemons running there are 2 ways to get to the printer, through usblp
and through hplip, printconf should prefer / only use the hplip uri, as that way
other functions of the device work too.
Comment 11 John (J5) Palmieri 2006-01-11 15:39:26 EST
Above (coment #9) should read clearer not cleared. 

So you are saying it is a cups backend?  Then we need to fix the hal backend to
dasy chain.
Comment 12 Hans de Goede 2006-01-11 15:56:46 EST
I think I'm saying that, I dunno what exactly makes up a cups-backend, what I
know / see is that if I:
-install hplip
-start the service
-start system-config-printer
-edit my printer
-select queue type tab

I see the following local-connected "queues":
/dev/lp0
/dev/usb/lp0
hp:/usb/psc_1300_series?serial=XXXXXXXXXXXXXXXXXX

By default system-config-printer uses /dev/usb/lp0, I changed this to
hp:/usb/psc_1300_series?serial=XXXXXXXXXXXXXXXXXX. I did this si that I can use
the scanner of the printer too. I assume that using /dev/usb/lp0 directly can
cause trouble when also using the scanner, I haven't tried though.

Note: both are the same printer.
Comment 13 John (J5) Palmieri 2006-01-11 16:45:15 EST
Yes hp is a cups backend.  I can easily daisy chain it but I have to figure out
the logic for deciding when to do this.  Can I do it for all hp printers?  If
that is so then it is totaly easy.  It looks like the port format is just
hp:/usb/<product name>?serial=<serial #> which HAL exports.

If I can't do it for all hp printers I guess I am just going to have to frob the
hp backend to give me a list of printers attached to the system it supports and
grok that list to see if the serial #'s match up.
Comment 14 John (J5) Palmieri 2006-01-11 17:01:32 EST
Actually I should point out what I am talking about and what Hans is talking
about are different issues but are related.  Hans you are setting it up by hand
and just noticed that the hp queue is listed last.  I'm guessing
system-config-printer should just pick the best queue to use.  I don't think
this will be fixed in the near term as we will be redesigning
system-config-printer and changes like this will get in then.

I'm talking about autodetecting printers which use the hal backend.  In my case
plugging in an HP printer should just work without going through
system-config-printer.  This bug report is very helpful in that respect.
Comment 15 Tim Waugh 2006-01-12 06:35:42 EST
I can fix up system-config-printer to automatically order 'hp'-provided devices
before any others.

J5: running the 'hp' backend with no parameters -- or alternatively, 'lpinfo -v
|grep " hp:"' -- will show you which attached devices the backend can drive.

I wish this weren't all so hacky. :-/
Comment 16 Matthias Clasen 2006-09-10 12:15:48 EDT
John, what is the status of this ? 
Do hp psc devices work out of the box in rawhide ?
Comment 17 Tim Waugh 2006-12-16 06:30:25 EST
Think I know how to fix this.
Comment 18 Fedora Update System 2007-01-18 12:19:59 EST
Fixed in update: hal-cups-utils-0.6.5-1.fc6

Note You need to log in before you can comment on or make changes to this bug.