GNOME Bugzilla – Bug 695286
Printer tool of GNOME Control Center does not get info about available printer devices from CUPS
Last modified: 2013-03-14 14:47:33 UTC
I am using Ubuntu Raring and if I choose the "Printers" section in the Control Center I get GNOME's printer setup tool. There I click the "+" button in the lower left for adding a printer. A pop-up comes up telling me that it is searching for printers. After some seconds I get a list of only network printers, no USB printers. So there are much less printers than I get with "lpinfo -v" on the command line or when starting system-config-printer on the command line. For me it seems that the new tool is using different detection methods, once direct detection of network-connected printers (Bonjour, SNMP, ...) and asking CUPS through D-Bus, via cups-pk-helper (org.opensuse.CupsPkHelper.Mechanism DevicesGet). The direct network detection seems to work, but the cups-pk-helper detection seems not to work, resulting in the USB printers (and the cups-pdf pseudo printer) missing.
Hi Till, does "/usr/lib/cups/backend/usb" or "gdbus call --system --dest org.opensuse.CupsPkHelper.Mechanism --object-path / --method org.opensuse.CupsPkHelper.Mechanism.DevicesGet 0 0 '["usb"]' []" list the usb printer? Regards Marek
Calling single backends works correctly, showing the printers detected by the appropriate backend. If logged in via SSH calling the "gdbus call ..." command as a normal user errors: Error: GDBus.Error:org.opensuse.CupsPkHelper.Mechanism.NotPrivileged: Not Authorized for action: org.opensuse.cupspkhelper.mechanism.devices-get (According to introspection data, you need to pass `iiasas') Calling the same command as root lists the results of the specified backend. If being in a terminal on the desktop of the machine the "gdbus call ..." command works also as a normal user.
Could you send me what does "dbus-monitor --session --monitor &> ./monitor.log" gives you during running of the new printer dialog? This will show me order of calling of DBus functions. Also, could you post here result of the "gdbus call --system --dest org.opensuse.CupsPkHelper.Mechanism --object-path / --method org.opensuse.CupsPkHelper.Mechanism.DevicesGet 0 0 '["usb"]' []". I would like to see whether it returns all required fields. Marek
I have run the following three commands and during eachj of them I have run the add-printer dialog, always getting no detected printers: dbus-monitor --session --monitor &> ./monitor-session.log dbus-monitor --system --monitor &> ./monitor-system.log sudo dbus-monitor --system --monitor &> ./monitor-system-root.log Then I have run the following command: gdbus call --system --dest org.opensuse.CupsPkHelper.Mechanism --object-path / --method org.opensuse.CupsPkHelper.Mechanism.DevicesGet 0 0 '["testbackend"]' [] > gdbus-call.log Note that I am on a virtual machine with no physical USB printers assigned to it. /usr/lib/cups/backend/testbackend is simply writing out autodetection results in the syntax expected from a CUPS backend. "lpinfo -v" and the above command seem to produce correct output. I have also run the command with an empty backend list: gdbus call --system --dest org.opensuse.CupsPkHelper.Mechanism --object-path / --method org.opensuse.CupsPkHelper.Mechanism.DevicesGet 0 0 [] [] > gdbus-call-empty-list.log This seems to assume the listing for all backends to be requested and the output looks appropriately. Is it possible that the GNOME tool is hard-listing a certain collection of backends and so manufacturer- or driver-supplied backends will get ignored, making it impossible to set up printers with certain third-party driver suites? This would also be a bug. All log files and testbackend are attached.
Created attachment 238312 [details] monitor-session.log
Created attachment 238313 [details] monitor-system.log
Created attachment 238315 [details] monitor-system-root.log
Created attachment 238316 [details] testbackend
Created attachment 238317 [details] gdbus-call.log
Created attachment 238318 [details] gdbus-call-empty-list.log
Seems that my assumption of the hard-listed backends is true, as now I have forwarded one of the host's USB printers to the VM so that the "usb" backend detects a printer and not only the unknown-to-GNOME "testbackend". With this I get this one printer listed, but as the "hplip" backend detects it, too, even twice, but indistinguishable for the user, which is another bug (should the list of detected printers not be sent to scp-dbus-service to sort out such duplicates?). I have tip for you how to ask for CUPS' autodetection results in a better way: Simply polling all backends at once by using the empty list will probably take to long time as the network detector backends snmp, dnssd, and bluetooth need a rather long time. Therefore I use a two-pass solution in system-config-printer: I make a list of "slow backends", currently snmp, dnssd, and bluetooth. Then I do two requests for detected printers, first a request with all but the slow backends and second, a request with only the slow backends. The CUPS API supports this by allowing to supply either a white list of backends, then all these are used, or a blacklist of backends, then all but these are used. Perhaps you should proceed the same way in the GNOME tool.
*** This bug has been marked as a duplicate of bug 693182 ***