Bug 154299

What exactly is "Control Center -> Printer Manager"?
Is it KDE or Gnome?

You must describe exactly waht we must do to reproduce it.
I don't know what you did exactly to "turn to administrator".

How did you set up the printers?
As far as i know the DeviceURI "hal:..." is not used by YaST
therefore I assume you used another tool.
If yes, does it work when you set up the printers with YaST?

Sorry, I'll try another approach.

from a gnome-terminal, as a user, I start gnome-cups-manager (that is the same as Control Center -> Printer Manager in Gnome). That was the program I used to add the printer too.

I right-click on a printer which is Paused. (img 1) I select properties, and in the Properties dialog, in the "General" tab, I see :

Status: Paused: Unable to open HAL device "hal:///org/freedesktop/Hal/devices/usb_device_3f0_c17_00CNFJ458453_if0_printer_noserial"
(img 2)

I push the button "Become Administrator" (img 2), write the password and the same dialog opens but now the status is Ready: (img 3)

Finally, if I start the gnome-cups-manager as root initially, I see the status to be 

Status: Paused: Unable to open HAL device "hal:///org/freedesktop/Hal/devices/usb_device_3f0_c17_00CNFJ458453_if0_printer_noserial"
(img 4)


I don't know how to duplicate it, as I don't know why whas caused the "Unable to open..." message.

The images mentioned will be uploaded immediately

Created attachment 70767 [details]
img 01 of the information

Created attachment 70768 [details]
img 02 of the information

Created attachment 70771 [details]
img 3 of the information

Created attachment 70772 [details]
img 4 of the information

I change the subject to
"Gnome Printer Manager shows inconsistent queue status"
and reassign it to the Gnome maintainers.

Regarding the other problem (why is it "Unable to open HAL device"):
Please file a seperated bug for this problem with the subject
"gnome-cups-manager uses CUPS backend hal which doesn't work"
and try to describe as far as you can remember what exactly you did
and test whether or not it works when you set up your printers with YaST.

Is cups-backends installed?  Did you configure the printers through Yast or GNOME?

cups-backends-1.0-7 is installed
the printer was configured through gnome-cups-manager.

BUT.. 
The HAL device sxists. If I disconnect the 2nd printer (and sometimes restart the system), it works as expected, i.e. I can print.


FYI, the same system, with the same printers (one laserjet and one Deskjet on USB both) has the same result (i.e. when I connect the Deskjet, I lose the laser) with

- NLD9 and the printers configured through YAST.
- Debian sarge 3.1r0a and the printers configured through CUPS.

So, it's probably a bug in the USB / printing code, which I will try to hunt down on another bug. Let's not mix that with gnome-cups-manager' s bug which is totally independent.

the gnome-cups-manager status problems seem to be related to not being able to open the hal device.  When it can open the device it gets a status of ready when it can't it reports the status as paused?

For your information regarding paused/stopped/disabled print queues
and regarding available (ready to use) versus unavailable backends
and regarding the two kind of USB DeviceURIs for CUPS, see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell#The_Backends

re #11, that link seems to indicate the new usb backend identifiers include a serial number which I haven't seen in practice, am I missing something?

Whether there is a serial number or not depends on the
particular printer (some models don't provide a value for
the "iSerial" USB item)

On my test machine I get

# /usr/sbin/lsusb -v | grep -B2 Serial

  iManufacturer           1 EPSON
  iProduct                2 USB MFP
  iSerial                 3 LJ4010410142027390
--
  iManufacturer           1 Hewlett-Packard
  iProduct                2 DeskJet 990C
  iSerial                 3 MX09R1T14QLH
--
  iManufacturer           1 HewLett Packard
  iProduct                2 HP LaserJet 1220
  iSerial                 3 00XXXXXXXXXX


On my test machine I get (first two lines wrapped):
--------------------------------------------------------------------------
direct usb://EPSON/Stylus%20Photo%20RX420 "EPSON Stylus Photo RX420"
 "USB Printer #1"

direct usb://HP/DeskJet%20990C?serial=MX09R1T14QLH "HP DeskJet 990C"
 "USB Printer #2"

direct usb://HP/LaserJet%201220 "HP LaserJet 1220" "USB Printer #3"
--------------------------------------------------------------------------

I don't know why some serial numbers are not shown here but
the second field is the correct DeviceURI which must be used
as is for CUPS if this kind of USB DeviceURI should be used.

Alternatively use an old-style USB DeviceURI like
usb:/dev/usb/lp0  usb:/dev/usb/lp1  usb:/dev/usb/lp1
but this old-stle URIs would become wrong if the printers
are disconnenced and reconnected in a different order.
I.e. the old-style USB DeviceURI works only o.k. if there
is only one USB printer.

I don't know about HAL in this case.

The hal backend shows on my test machine:
--------------------------------------------------------------------------
direct hal:///org/freedesktop/Hal/devices/usb_device_4b8_80f_LJ4010410142027390_if1_printer_noserial "EPSON Stylus Photo RX420" "EPSON Stylus Photo RX420"

direct hal:///org/freedesktop/Hal/devices/usb_device_3f0_3304_MX09R1T14QLH_if0_printer_MX09R1T14QLH "HEWLETT-PACKARD DESKJET 990C" "Hewlett-Packard DeskJet 990C"

direct hal:///org/freedesktop/Hal/devices/usb_device_3f0_417_00XXXXXXXXXX_if0_printer_noserial "Hewlett-Packard HP LaserJet 1220" "Hewlett-Packard LaserJet 1220"
--------------------------------------------------------------------------

In general a backend must report the correct DeviceURI
and a printer config tool should simply use what the backend
reported and if this doesn't work it is not a fault of the
printer config tool.

re #15

The reason I ask is we are trying to map hal events (added and removed) back into the DeviceURI that cups associates with the printer.  If the printer is configured with the hal backend this is 1 to 1 and trivial to do (which is why the hal backend was created as far as I know), if the printer is configured with the new style usb uris but the uri doesn't contain the serial number the mapping is many to 1 and I was hoping to figure out when that would occur.  #154596 pertains to this issue.

I'm seeing the same behaviour with a Stylus Photo 820 as you are with the Stylus  Photo RX420.  Do you have any idea what would happen if more than one of that model printer were attached to the same computer?

I don't have more than one of those models.
Even if I had two same models, you cannot rely on what happens
for any other two same models.
All you can rely on is what the particular CUPS backend outputs.
I.e. you would have to run the CUPS backend and parse its output.

What I don't understand here is:
You wrote "map hal events (added and removed) back into the DeviceURI".
Why do you wnat to do it at all?
The new-style CUPS USB DeviceURI is perfectly o.k. even if there are
many USB printers which are connected/disconnected in random order.
Which problem do you want to solve with your hal event processing?

Ok, I can understand the confusion.  Think of someone plugging a printer into a machine for the first time.  We'd like to be able present them with a dialog to configure that printer for use with cups.  So if we receive an add event from hal for a printer we want to be able to check if that particular printer is already configured with cups.  If not we want to offer the option to configure that printer.  To do that we need to be able to map the hal udi we get from the add event back to the DeviceURI cups is using to verify that the printer is configured.

The problem we are having is that the usb backend has multiple ways of referring to exactly the same printer, and it appears that even for the new style usb uris the backend performs its own subsitutions of the usb vendor and model strings.  This puts us in a situation where we can't reliably test if a printer that has just been added has already been configured.

Yes, you cannot reliably test if a printer which has triggred
a HAL event is already configured or not.

Only if you have a serial number and find it in an existing DeviceURI
entry in /etc/cups/printers.conf, you know that for exactly this
printer there exists already a queue.

Have all the other possible backends for USB printers in mind, like:

The "hp" backend which is included in HP's printing and scanning
software HPLIP (package hplip), example device URIs:
-------------------------------------------------------------------------
direct hp:/usb/DESKJET_990C?serial=MX09R1T14QLH 
 "HP DESKJET_990C" "hp:/usb/DESKJET_990C?serial=MX09R1T14QLH"

direct hp:/usb/HP_LaserJet_1220?device=/dev/usb/lp2 
 "HP HP_LaserJet_1220" "hp:/usb/HP_LaserJet_1220?device=/dev/usb/lp2"
-------------------------------------------------------------------------

The "ptal" backend which is included in HP's old printing and scanning
software HPOJ (package hp-officeJet), example device URI:
-------------------------------------------------------------------------
direct ptal:/mlc:usb:DESKJET_990C "HEWLETT-PACKARD DESKJET 990C"
 "PTAL mlc:usb:DESKJET_990C"
-------------------------------------------------------------------------

The "epson" and "canon" backends from Gimp-Print
(package cups-drivers-stp), example device URIs:
-------------------------------------------------------------------------
direct epson:/dev/usb/lp0 "EPSON USB MFP" "USB Printer #1"

direct canon:/dev/usb/lp1 "CANON" "USB Printer #2"
-------------------------------------------------------------------------
Note the exact and verbose model names "EPSON USB MFP" and "CANON"
which make it also impossible to check for same or similar
model names ;-)

Third-party backends from whatever printer manufacturer
which are needed to support non-generic printer features
(e.g. device info and device maintenance as for example
the "hp" backend does for HP printers).

Don't forget the "beh" backend wrapper
http://www.linuxprinting.org/beh.html
which is included in Suse Linux 10.1

I fond something which may help you in at least one case:
To answer the question if a printer is already configured or not
by YaST (i.e. in particular the state after system installation).

When a printer is configured with YaST, files like
/var/lib/hardware/udi/org/freedesktop/Hal/devices/usb_device_*_printer_*
are created by YaST (I assume via hwlib calls) for example:

/var/lib/hardware/udi/org/freedesktop/Hal/devices/usb_device_3f0_3304_MX09R1T14QLH_if0_printer_MX09R1T14QLH
/var/lib/hardware/udi/org/freedesktop/Hal/devices/usb_device_3f0_417_00XXXXXXXXXX_if0_printer_noserial
/var/lib/hardware/udi/org/freedesktop/Hal/devices/usb_device_4b8_80f_LJ4010410142027390_if1_printer_noserial

Those files contain in particular a line
  hwinfo.configured = '...'
where the value for '...' is either 'yes' or 'no'.

I don't know if any other printer setup tool (except YaST) uses hwlib
and/or if other tools also have some kind of HAL support.

Created attachment 76388 [details]
/var/lib/hardware/udi/org/freedesktop/Hal/devices/usb_device_*_printer_*

tar.gz of example HAL files which are created by YaST printer config.

> Regarding comment #19 item 2.:
> Forcing the user fixes nothing.
> Free software is about freedom - in particulat freedom of choice.
> Of course you are also free to develop anything you want.

yes, it's about freedom, but as with all software development (free or otherwise), it's about solving problems. forcing the use of the hal backend over the usb backend fixes problems.

You argue that forcing the use of the hal backend is bad... yet you are perfectly happy forcing the usb backend on people. Why? That's the most hypocritical argument I have ever heard!

Moving to using the hal allows all software that wants to do anything with hardware a COMMON NAMING CONVENTION for identifying pieces of hardware. the usb backend has many naming conventions that are UNGUESSABLE by any other piece of software.

THINK OF THE WONDERFUL POSSIBILITIES!! that switching to hal gives us... the current setup with everything using different ways of identifying the same damn piece of hardware is a NIGHTMARE to say the least.

> Regarding comment #19 item 3.:
> You cannot guess how often I heard it.
> So you really think that optimizing the best case
> (a printer for which an appropriate PPD can be autodetected)
> really helps to solve any of the real problems?
> Fell free to optimize the best case as you like.

Allow me to steer you in the correct direction: When a user plugs in a new printer (unconfigured), it is a very nice convenience for our desktop software to assist the user by opening the print configuration program for them so they don't have do dig for it in the menus. Can we at least agree on this point?

Okay, now that we have agreed on that, you seem to be confused into thinking that we are trying to auto-configure the printer 100% without user intervention... that's the only excuse I can think of for your above comment. We are NOT trying to do this. We are simply opening the printer configuration program for the user, filling out as many useful details as we can ACCURATELY EXTRACT to remove a lot of the tedious work for the user.

We ship a number of products that extract info from, say, /etc/passwd to auto-fill-in the user's name in entry boxes, but I don't see you shooting that software down. Double standard maybe? That's what it sounds like to me.

> Regarding comment #19 and 20:
> Do you think it is really worth the effort only to get an automated
> popup for a new-connected printer?
> Do you think it would really be so bad when a user must maually start
> the printer config tool for a new-connected printer?
> Do you think that an automated start of the config tool really makes
> those users happy who have a real problem because there is no matching
> PPD or no matching driver for their printer?

Your lack of touch with our user-base astounds me.

YES it is worth making the lives of our users easier. What do you think we're trying to ship, here? A product doomed to complete and utter failure to compete? Do you just want to throw in your towel and give up?

Missing PPD files is a completely separate problem, COMPLETELY UNRELATED to the problem at hand.

I think, I should mention why I prefer the usb backend before the hal backend
either:
a) the customer gets help for his usb choice on the public cups mailing lists, whereas the hal backend is widely unknown to the community (printing was excluded from the free installation support for our Linux distribution in the past)
b) the usb backend is longer in use then the hal backend, and therefore the usb backend is more well-known.
c) the usb backend doesn't change as frequently as the hal system does
d) the usb backend has got real-life patches, like HP is naming its printers sometimes "Hewlett-Packard" and sometimes "HP". There is uniq mapping present in the usb backend. Or the problem with the status encoded into the device name (vendor name forgotten), cups usb backend truncates this information in the backend; don't know, if hal is doing the same...
e) the usb backend will work after an upgrade to cups-1.2, whereas the hal backend needs to be recompiled by Novell before the user can use it.


I doubt that the names of the USB backend are "unguessable". If you have a look at the documentation, you will notice that it is always the same scheme for a name, and as mentioned (see d)) there is a better naming of devices.

b) more well-known isn't necessarily better
c) the hal system isn't changing that much and the udi strings haven't changed. hal is already widely used and becomming even more so with time.
d) this is exactly why we need to move away from the usb backend, any other piece of software trying to guess what the usb uri the CUPS backend is using this week is an impossible task to do with any guarantee. HAL does not have this problem.
e) customers (and I don't mean people who download the free version) are going to continue to get Novell packages because they will want our support. when a user does install a non-Novell CUPS package and things stop working, they'll be coming to us and we can point them at our packages. it's not that hard.

And yes, they are unguessable.

Here are the following formats that the usb backend uses:

usb:/dev/usblp0
usb:/dev/usb/lp0
usb://HP/Deskjet%203550
usb://Hewlet-Packard/Deskjet%203550
usb://Hewlet%20Packard/Deskjet%203550
usb://HP/Deskjet%203550?serial=DJ52745290
usb://Hewlet-Packard/Deskjet%203550?serial=DJ52745290
usb://Hewlet%20Packard/Deskjet%203550?serial=DJ52745290


which one is the usb backend using? how many licks does it take to get to the tootsie roll center of a tootsie roll pop? one may never know.

There may be other naming conventions that the usb backend uses, god knows. but I do know for a fact that at least those listed above are all possible URI's for the same printer.

And yes, I've read the documentation but in practice it is inaccurate to say the least.

It's been explained to me that some printers don't have serial #'s that are queryable and that is why the usb backend sometimes doesn't contain the ?serial=# bit, but I can prove that to be bullshit. I have a Lexmark printer here that HAL is perfectly capable of getting a serial# for but the usb backend still calls it

usb://Lexmark/Z700-P700%20Series

e.g. no serial#

how am I supposed to tell 2 printers apart if they are the same vendor/model? Oops, I can't. Now is that a real concern? I don't know, but there are bug reports where people have multiple printers in this bugzilla, so it doesn't seem all that far-fetched.

Also note the old usb formatted URI's that have the device node... if I turn my printers on in a different order one day, they might get assigned different device nodes :)

With HAL, this is not a problem.

Your imagination about device names from the usb backend is really impressive. Fact is that you ignore that a specific vendor has always the same name at the usb backend (as long as he doesn't change it in the firmware), and all specific models of him have also a fix string.

If the HP Desktop 3550 line has the ability of reporting a serial number via usb, then it is included into the name of the usb backend; otherwise not.

There were many problems with the kernel in the past regarding printer names, which were fixed via the usb backend, e.g. https://bugzilla.novell.com/show_bug.cgi?id=49754
These problems are not fixed in the hal backend, as it relies on the ability of the kernel/hal to address this problems. My experience is that you should on rely on that.

As you are the author of the hal backend, you should be more open to any other suggestions, and you should not be ignorant to other backends (which consist of a lot of real-life experience and bugfixes), and should not insist on the opinion, that HAL is and was always failure free.

your imagination of my imagination is really quite impressive.

here's the uri I get from the usb backend when plugging in one of my usb printers:

usb://3550?serial=TH3741451H76

where's the vendor name in that uri? OOps, I thought you claimed the vendor name would always be there? Guess you are mistaken ;)

currently lpstat -v will print the following for my lexmark/hp configured printers:

lpstat -v
device for printer: usb:/dev/usb/lp0
device for printer_1: usb://3550?serial=TH3741451H76

So who's imagining things now?

> If the HP Desktop 3550 line has the ability of reporting a serial number via
> usb, then it is included into the name of the usb backend; otherwise not.

Both the HP *AND* the Lexmark have this capability, but the Lexmark never ever gets the serial# even tho HAL is able to get one.

You guys have clearly failed to actually TEST any of this like Larry and I have, so you are in your own little dream worlds where the usb backend actually uses consistant URI schemes - which it does not.

Your failure to see this is what is frustrating me. You say one thing but I can PROVE you wrong and have done so.

If you are SO confidant that you are correct, then PLEASE send me code to take a HAL UDI and output the correct usb backend URI for any given printer. If you can't do that (and I guarantee you can't), then this really is a problem and using the HAL backend would solve this.

Well, we don't have every printer here, so I cannot proof this special model. But I can tell you, that the HP LJ 2550 is working perfectly, when using the usb backend:
 direct usb://HP/color%20LaserJet%202500 "HP color LaserJet 2500" "USB Printer #1"

Comments:
a) your information is not complete :( it doesn't show the complete output of the usb backend.
b) you never made any bugreport against cups regarding this. :(
c) you suddenly show only ONE name for a printer and no longer 8 names for a single printer. Previously you showed us 8 names for the same printer.

usb backend is running, even there is no HAL daemon running.

Nevertheless. Please tell me, if your hal backend is working together with a HP officejet printer, for both: printing and scanning!
A small hint: you should use the hplip drivers (hpijs), as they contain the only working drivers for some HP OfficeJet printers, like the HP OJ 4150. 

Hope your filling out a bugzilla report for CUPS! If so, please provide
 /proc/bus/usb/devices
and the content (ascii dump) of:
  char device_id[1024];
  ...
 ioctl(fd, LPIOC_GET_DEVICE_ID(sizeof(device_id)), device_id);
TIA

> c) you suddenly show only ONE name for a printer and no longer 8 names for a
> single printer. Previously you showed us 8 names for the same printer.

my point with the 8 names was to show that there were potentially 8+ uri schemes that the usb backend might choose to use, not to claim that my printer had 8 usb uri names, I was merely using "HP Deskjet 3550" as an example printer (which also happens to be one that I have available to me for testing and for which really is named improperly by the usb backend).

anyways, I am now reporting CUPS bugs to bugzilla. Have a lot of fun :)

Larry I'm guessing re-working the printing stuff to not use hal solves this?

JP I'm not sure if it solves the original issue.  Can the reporter verify that if the printers are removed then configured again using yast that the status is correctly reported?

Hi,
In SLED 10 Beta 10 the behavior is as following.
Evereytime I turn on Laserjet 1010, gnome-cups-add pops up automatically asking for root password. The originally added Laserjet is set as "Paused".
The behavior is the same as previously, i.e. as a user I can see that the printer is Paused because "Paused: Unable to open USB device "usb://HP/LaserJet%201010": No such device"", but when I press the button named "Become Administrator" and write the root password, the status changes to "Ready".
With regard to my comments 3,4,5,6,7 the only thing that has changed is the reason for "paused". It used to be HAL-related, now it is USB-related.

Do you want me to try remove the printers and re-add them using Yast (in SLES 9, the same printers, using YaST to be configured, needed reconfiguration every time, so somehow I don't think that will solve the problem).

Michalis, in #2 you mention that if you start gnome-cups-manager as root you also get the permission denied message.  Is this still the case?

Larry,
I never get the "permission denied message" 
When I open as any user gnome-cups-manager and the printer is not available (for whatever reason), I see the message that the printer is paused (for whatever reason). There is a button there, that is named "Become Administrator". If I press this button (in order to make the printer available again), I see the printer as Ready.
That is wrong. The printer should say paused, because it is paused...
If I open directly gnome-cups-manager (i.e. I don't use the Become Administrator button, but instead I open a gnome terminal, su to root and execute gnome-cups-manager as root), I see the printer as paused and finally have the ability to restart it.

The bug is triggered by pressing the button "Become administrator"
Thank you

Ok, I think the issue is that when the new dialog is launched it passes the printer name on the command line and for some reason that name is matching the wrong printer.  Can you please include the exact command line that is presented in the password dialog and a list of all the printers configured on the system.

Michalis, any chance I can get that information?

Hi,
the name matching is the correct one.
The command is: 
gnome-cups-manager -p LaserJet-1010

Try to print a page to a printer that is not turned on.
Then it should be "Paused" and if I'm not wrong, you can follow the procedure described to duplicate the bug.

Info was provided.

Ok, found the bug patch in a few minutes.

Packages at w3.suse.de/~lewing  In the process of testing this I've found some other issues I'm going to resolve as well before I submit the update.

update submitted to stable and sled10.

*** Bug 190094 has been marked as a duplicate of this bug. ***