Bug 1052203

Created attachment 849371 [details]
Adding printer with system-config-printer

First thought: with system-config-printer you are just telling it where/how to print, rather than letting it work it out like control-center has to.

Maybe you could try looking in the "Network printers" part of the device list to see if it found the device like control-center did?

Maybe you should let it try working out which driver to use, to see if it has the same problem control-center does?

The behaviour in the control-center video is certainly odd though. I'm not sure what the 'Installing' state means as opposed to 'Configuring'. It may take several minutes to find and install the driver though -- how long did you leave it?

On system-config-printer...I tried it initially but it doesn't "autodiscover" it so I had to manually specify protocol and ip.

Regarding the driver...It doesn't find it.  I'm presented with the "Choose Driver" window with the 3 options:  Select printer from database, Provide PPD, Search for printer driver to download.  That's where I provide my PPD file.

Regarding the gnome tool I left it there for about 7 minutes...

Hi Jorge,

could you paste here what "lpinfo -l -v" returns for the printer under root?

Regards

Marek

It seems that this is a problem in system-config-printer. Specifically in its DBus method GetBestDrivers. It doesn't close the message dialog when the search is over.
I think that since the message dialog is iterated manually it needs also some iterations to hide so I tried to add some iterations after the hide and it closes successfully (see the attached patch).

You can reproduce this by running:

gdbus call --session --dest org.fedoraproject.Config.Printing --object-path /org/fedoraproject/Config/Printing --method org.fedoraproject.Config.Printing.GetBestDrivers "MFG:Xerox;CMD:HBPL;MDL:Phaser 3250;DES:Xerox Phaser 3250;CLS:PRINTER;STS:AAARBAD/AP8AAAAAAAQAAWQDZANkA2QDAAAAAAADUAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAQDA==;" "Xerox Phaser 3250 (XRX0000AAAFC993)" "dnssd://Xerox%20Phaser%203250%20(XRX0000AAAFC993)._pdl-datastream._tcp.local/"

The problem shows after second run of this command.

Unfortunately, the patch doesn't help when you run the command three times (just when you run it twice).

Created attachment 850570 [details]
patch fixing hiding of the message dialog

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

Marek,

Here's the output:

Device: uri = lpd
        class = network
        info = LPD/LPR Host or Printer
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = socket
        class = network
        info = AppSocket/HP JetDirect
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = http
        class = network
        info = Internet Printing Protocol (http)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipp
        class = network
        info = Internet Printing Protocol (ipp)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = https
        class = network
        info = Internet Printing Protocol (https)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hp
        class = direct
        info = HP Printer (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = serial:/dev/ttyS0?baud=115200
        class = serial
        info = Serial Port #1
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipps
        class = network
        info = Internet Printing Protocol (ipps)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = beh
        class = network
        info = Backend Error Handler
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = smb
        class = network
        info = Windows Printer via SAMBA
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hpfax
        class = direct
        info = HP Fax (HPLIP)
        make-and-model = Unknown
        device-id = 
        location =

And this is my info (duplicate bug)

Device: uri = ipps
        class = network
        info = Internet Printing Protocol (ipps)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = beh
        class = network
        info = Backend Error Handler
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = http
        class = network
        info = Internet Printing Protocol (http)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = https
        class = network
        info = Internet Printing Protocol (https)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = lpd
        class = network
        info = LPD/LPR Host or Printer
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = socket
        class = network
        info = AppSocket/HP JetDirect
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipp
        class = network
        info = Internet Printing Protocol (ipp)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hp
        class = direct
        info = HP Printer (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = serial:/dev/ttyS0?baud=115200
        class = serial
        info = Serial Port #1
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = smb
        class = network
        info = Windows Printer via SAMBA
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hpfax
        class = direct
        info = HP Fax (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = dnssd://MF8030-393462._pdl-datastream._tcp.local/
        class = network
        info = MF8030-393462
        make-and-model = Canon MF8030
        device-id = MFG:Canon;MDL:MF8030;FZY:0;
        location =

Thanks for the patch.

It looks like the remaining problem is because of the openprinting driver download support Till added last year. Really that needs to be re-factored into the ppdsloader, avoiding the need to run an inner main loop.

When the proble shows after the second (with patch after the third) run, it looks like that on the first run some structure is set up which should get removed in the end but actually does not get removed, perhaps main loops which get concurrently running (only a guess).

Yes, it does look like that. I couldn't track down what was wrong.

I'm sure re-factoring that code would fix it, but I don't have the time to look at that right now (anyone else?). In the mean time I can disable the openprinting driver download part of the D-Bus service.

Created attachment 912477 [details]
/scp-dbus-service-do-not-hang-when-searching-openprinting-for-drivers.patch

The problem seemed to be the "Searching for drivers" pop-up which was opened without having an actual new-printer dialog as parent.

The previous patch only fixed the "Searching for drivers" pop-up not diosappearing on the second run. Independent of this, the first two runs delivered the correct answer and any further run was hanging, leading to a timeout of the "gdbus call ..." command, requiring manually killing the scp-dbus-service process.

The attached patch solves both problems, once containing the previous patch and second, not popping up the "Searching for drivers" window and with this also not attending the GTK events (no "Gtk.main_iteration()" calls) if we are running NewPrinter in the "download_driver" dialog mode (which means that we have called it only for finding and downloading a driver via OpenPrinting).

Please check this patch. It should eliminate the hang, but it also removes the "Searching for drivers" pop-up (here the client should take care of telling the user that the search will take some time).

The patch will not change the behavior of the system-config-printer GUI, doing the driver check in s-c-p, the "Searching for drivers" pop-up will still appear.

I don't think that gets to the heart of the problem. It does solve the test case as presented, but the basic issue seems to be that any UI interaction can cause a deadlock.

I see the same deadlock, for instance, if I tweak the search to look for a Ricoh Aficio 3260C -- a model for which openprinting.org offers PPDs. It does the query, and hangs once it tries to present the dialog. (It worked a couple of times.)

system-config-printer-1.4.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/system-config-printer-1.4.5-1.fc20

Package system-config-printer-1.4.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing system-config-printer-1.4.5-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8100/system-config-printer-1.4.5-1.fc20
then log in and leave karma (feedback).

(In reply to Tim Waugh from comment #14)
> I think I can answer those two:
> 1. The manufacturer's driver sends PostScript, so the printer has to do the
> rendering itself and may take time to do so, whereas gutenprint renders the
> job before sending it to the printer. That's my guess at why.
> 2. It does get installed for me, and used by default. The reason it didn't
> for you is most likely bug #1052203
> 
> There's another question actually: is the bad quality/extra page issue due
> to Firefox reprocessing the PDF in some way, or due to some job option it's
> providing?
> 
> The way to find out is to take a look at the job options for one of the test
> jobs you've tried.
> 
> Using system-config-printer (the "Print Settings" application), could you
> please right-click on the printer and select View Print Queue, then click on
> the 'Show completed jobs' button (2nd one on toolbar).
> 
> Right-click on one of the jobs sent from Firefox, and select 'View
> Attributes'. Could you please maximise that window to the height of the
> screen and take a screenshot? (Might need to take more than 1)
> 
> Thanks.


After update still installer gutenprint driver by default
Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQOWd3Ukp0RmxFRFk/edit?usp=sharing

[mikhail@localhost ~]$ rpm -q system-config-printer
package system-config-printer is not installed
[mikhail@localhost ~]$ rpm -qa | grep system-config-printer
system-config-printer-libs-1.4.5-1.fc20.noarch
system-config-printer-udev-1.4.5-1.fc20.x86_64

system-config-printer-1.4.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Generally, openiong windows, performing OpenPrinting queries, or installing a driver out of the scp-dbus-service is not problematic with the currecnt implementation. What is broken is creating an instance of the NewPrinterGUI class and opening the new printer wizard only delayed or not at all.

I come to this conclusion by triggering the full new printer wizard out of the scp-dbus-service running a command like

scp-dbus-service --client file:/tmp/printout --devid 'MFG:EPSON;MDL:EP-805A Series;'

This opens the wizard first, then searches for local drivers, fails as this printer is locally unsupported, then looks it up on OpenPrinting and opens the download interface. This I can repeat arbitrarily many times without scp-dbus-service hanging (repeat within 30 sec after previous run). If I wait more than 30 sec without repeating, scp-dbus-service closes as expected.

The problem of the wizard (driver download page) not starting up and/or the scp-dbus-service getting unresponsive I only get by calling a D-Bus method which only searches for driver (either local + OpenPrinting or OpenPrinting only) and then opens the wizard for download (and only for that) if needed. This leads to the wizard not opening and then scp-dbus-service hanging and even if no download is possible (query printer which does not exist at all) and so no attempt of opening the wizard takes place leads to scp-dbus-service hanging.

When doing the tests leading to the observations of my previous comment, I did not only use the GetBestDrivers method (which has its own inner main loop) but also the DownloadDriverForDeviceID (which does not have an own main loop).

Also the OpenPrinting query works when the new printer wizard window is opened immediately.

What needs to get checked is whether either the instance of NewPrinterGUI gets destroyed/freed when the request is completed or whether subsequent requests re-use the existing instance instead of opening a new instance every time.

What I am thinking about what could work better is that scp-dbus-service calls system-config-printer via command line with special options for the different interactive (window-opening) tasks. So with this we have for sure cleaned up after each task and tasks are not interfering with each other. WDYT?

Thanks for investigating this some more. However, I think I'd rather fix the locking problem, as it might have implications for other parts of the D-Bus service.

I looked into whether the NewPrinterGUI object gets properly freed after each call, and you're right, it doesn't. I've fixed that now.

I've pushed a 'dbus-fixes' branch which contains these fixes:
* re-write the bits that used an inner loop in scp-dbus-service.py so they are asynchronous instead
* call 'destroy' on the NewPrinterGUI object to make sure it gets cleaned up
* don't re-create the global FetchedPPDs object, just make it reload PPDs

I still see the same problem. After the second iteration of the call from comment #5, the D-Bus service is stuck trying to grab the GDK lock.

It just needs a bit of debugging on why the lock is getting stuck there.

I think the reason for the deadlock is that nextNPTab() is having to call Gtk.events_pending()/Gtk.main_iteration() in several places, but it can't know whether it's safe to do so.

I've pushed a commit on the dbus-fixes branch that removes those calls, and I no longer see deadlocks.

The real fix will be to re-work the openprinting driver search code (and parts of nextNPTab) so that it is properly event-driven, i.e. it starts a query going, and when that query finishes a signal is emitted which a handler can pick up to deal with the query result.

I have now tried system-config-printer without any patches ad it locks up immediately, probably on the attempt to open the wait pop-up window. Thereseems to be something wrong with scp-dbus-service having been changed to the GTK main loop to fix bug 1116756.

Please try this fix:
  https://git.fedorahosted.org/cgit/system-config-printer.git/commit/?id=34f9dc9e4fa348d7a25b2444cf2d1fe2a8968536

Tim, thank you very much. The immediate crash is fixed now.

I've reproduced this same issue locally (system-config-printer 1.4.3), and can finally install the printer without deadlocks after applying the patches in the dbus-fixes branch (which now includes the one in comment #25).

However, I can't see the "Searching for drivers" dialog anymore, but just the gnome-control-center main window in an insensitive state for the time that scp-dbus-service.py is working, returning the control the user as soon as it's done.

I guess that's perhaps expected (the "Searching" dialog not showin up) as those patches have not been merged yet (so I believe they are experimental stuff at the moment), but asking anyway just in case.

Thanks in advance

I haven't been able to look at this yet but I hope to get to it soon.

I've fixed this upstream now.

There are a sequence of cupshelpers.openprinting calls each time we want to perform a search. I've grouped these together into an OpenPrintingRequest GObject, one which emits signals when it has finished.

The two different places we do this from now each connect their signal handlers as appropriate, and nextNPTab does not block waiting for the request to complete.

Till, I've removed some code to do with downloading binary packages as I wanted to get it working correctly for PPD files in the first place. Perhaps you could take a look at the places where installdriverpackage had previously been called?

The upstream commit is this one:
  330bfe3570d9821eadc72066cf6371dd71216aa7