Bug 1784449 - [RFE] GTK should support cups temporary queues when the device is available via Avahi
Summary: [RFE] GTK should support cups temporary queues when the device is available v...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk3
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1908134 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-17 13:33 UTC by Zdenek Dohnal
Modified: 2021-02-15 12:59 UTC (History)
13 users (show)

Fixed In Version: gtk3-3.24.25-1.fc33 gtk3-3.24.25-1.fc34 gtk3-3.24.25-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-15 10:46:47 UTC
Type: Bug


Attachments (Terms of Use)
cupsd log for evince (54.95 KB, text/plain)
2020-01-03 07:31 UTC, Zdenek Dohnal
no flags Details
cupsd log for libreoffice (176.18 KB, text/plain)
2020-01-03 07:32 UTC, Zdenek Dohnal
no flags Details
fix for some issues (3.32 KB, patch)
2020-03-19 14:52 UTC, Marek Kašík
no flags Details | Diff
gtk debug (2.63 MB, text/plain)
2020-05-20 07:50 UTC, Zdenek Dohnal
no flags Details

Description Zdenek Dohnal 2019-12-17 13:33:46 UTC
Hi,

there is cups temporary queues feature in CUPS since 2.1.x and it would be good if evince was able to work with them.

What is cups temporary queue?
-----------------------------

It is a queue, which is designed to show up only when an user needs it - during printing dialog. It disappears after successful printing. This feature is supported by most printers released 2010 and newer and it uses IPP 2.0 protocol for getting all needed information about printer (instead of installing ppd file) and Avahi for discovering printer.

How to find out that printer supports such behavior:
----------------------------------------------------

You can f.e. see it in output of 'sudo lpinfo -l -v':

Device: uri = ipp://EPSONAB3686.local:631/ipp/print
        class = network
        info = EPSON WF-C5710 Series (driverless)
        make-and-model = EPSON WF-C5710 Series
        device-id = MFG:EPSON;MDL:WF-C5710 Series;CMD:PWGRaster,AppleRaster,PWG,URF,JPEG;
        location = 

or you can see it by 'lpstat -e'.

You can ask for it through CUPS API - more info[1].

Libreoffice already supports this feature correctly, so you can see how the process should look like.

Evince currently shows the temporary queue named 'print' which is not working.

Would you mind coordinating with upstream and finding out how it should be solved?

[1] https://www.cups.org/doc/cupspm.html#finding-available-destinations

Comment 1 Marek Kašík 2019-12-17 14:06:47 UTC
Hi Zdenek, I believe, that his should work in current gtk 3.24 upstream. I've finally pushed fixes for this last week. Could you try whether the 2 commits fixes the bug for you?

https://gitlab.gnome.org/GNOME/gtk/commit/725892b65362956ef40752dc446cd3dab248a444
https://gitlab.gnome.org/GNOME/gtk/commit/fb2fa8348d87024d94905ed94f9f78149726df88

Comment 2 Zdenek Dohnal 2019-12-17 14:53:50 UTC
Nice, thank you!

I'll check it this week.

Comment 3 Zdenek Dohnal 2020-01-03 07:30:55 UTC
Hi Marek,

I'm sorry for the delay - I hope you enjoyed the holidays.

I backported commits you mentioned and commit https://gitlab.gnome.org/GNOME/gtk/commit/58cfa3fd4956332797f0dd35563cdccb1e0323ea into gtk3 for Fedora 30, built and installed gtk3, gtk3-devel and gtk-update-icon-cache packages (the ones I had installed before testing), but printing does not work.

The job is not created in cupsd at all (did not receive any Create-Job or Print-Job requests which initiate jobs).

From the logs, gtk is using CUPS-Get-Printers request which is deprecated for this use case. It returns only locally created permanent queues and does not work for temporary queues - IPP request Get-Printer-Attributes and using destinations works for both cases - for permanent and temporary queues.

I'm attaching cupsd log for evince (you can see only Get-Printers requests) and for Libreoffice, which is not following exactly CUPS programming manual (does not use cupsEnumDests, but uses Create-Local-Queue request, which does the trick before sending Get-Printer-Attributes) but it does the trick too.

Comment 4 Zdenek Dohnal 2020-01-03 07:31:33 UTC
Created attachment 1649331 [details]
cupsd log for evince

Comment 5 Zdenek Dohnal 2020-01-03 07:32:02 UTC
Created attachment 1649332 [details]
cupsd log for libreoffice

Comment 6 Marek Kašík 2020-01-03 12:14:00 UTC
Hi Zdenek,

thanks for testing this. I search for the printers via Avahi itself so I don't use CUPS' functions for listing printers. And for printing I connect directly to the remote printer not creating a print job via local CUPS server (but using CUPS for this).
Did you use a remote printer for the test or a remote CUPS server? The remote CUPS' logs could shed some light on this.

Comment 7 Zdenek Dohnal 2020-01-03 13:57:51 UTC
My printer is in my local network. My laptop has access to it, it is visible via Avahi, but cups-browsed is turned off - so I do not have any cupsd log from server and AFAIK my printer does not have any logs in its web interface.

IMO Gtk should be able to see and print to IPP eve printer even without cups-browsed running i.e. be able to support cups temporary queues, because it confuses users.

> I search for the printers via Avahi itself so I
> don't use CUPS' functions for listing printers. And for printing I connect
> directly to the remote printer not creating a print job via local CUPS
> server (but using CUPS for this).

Unfortunately, your steps do not work for temporary queues, because you do not have any queue in CUPS which you are trying to connect to. IMO you could create it by that Create-Local-Queue request and then connect to it (like libreoffice does it), or use CUPS destinations.

When you turn on cups-browsed, it creates local permanent queue based on Avahi response and this queue works - the downside of this you need to have cups-browsed running.

Comment 8 Marek Kašík 2020-01-21 17:46:31 UTC
I'm sorry for the obvious question :). Isn't it blocked by firewall or something on your network?

What information about the printer do you get from avahi-discover tool (for ipp or ipps services)? (all the TXT and other fields)

Comment 9 Zdenek Dohnal 2020-01-22 09:13:18 UTC
Np, I'll check it when I'll be WFH.

Comment 10 Zdenek Dohnal 2020-03-18 12:39:52 UTC
(In reply to Marek Kašík from comment #8)
> I'm sorry for the obvious question :). Isn't it blocked by firewall or
> something on your network?

Hmm... I have mdns and ipp enabled in my firewall and I can ping the printer and connect to port 631.

> 
> What information about the printer do you get from avahi-discover tool (for
> ipp or ipps services)? (all the TXT and other fields)

Service Type: _ipp._tcp
Service Name: HP LaserJet M1536dnf MFP (42307C)
Domain Name: local
Interface: enp0s25 IPv4
Address: NPI42307C.local/192.168.1.112:631
TXT priority = 10
TXT adminurl = http://NPI42307C.local.
TXT rp = ipp/printer
TXT UUID = 434e4239-4243-4a42-5859-3c4a9242307c
TXT Scan = T
TXT Duplex = T
TXT ty = HP LaserJet M1536dnf MFP
TXT product = (HP LaserJet M1536dnf MFP)
TXT note = 
TXT Color = F
TXT pdl = application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf
TXT URF = CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600
TXT qtotal = 1
TXT txtvers = 1

Comment 11 Zdenek Dohnal 2020-03-18 13:07:04 UTC
But I have tp-link router between laptop and printer - but it is in the same network and accessible via Avahi, so I don't know what else should block communication needed by gtk.

Comment 12 Marek Kašík 2020-03-18 13:30:44 UTC
I'm looking at this issue right now. I have a printer here on which I can reproduce it. It seems that there are places where wrong resource path was used inside gtk. But I'm facing another issue. Once I send the print data to the printer via IPP_PRINT_JOB the connection is reset.

Comment 13 Zdenek Dohnal 2020-03-18 14:23:57 UTC
It is reset from cupsd side or the printer side? According IPP specification, cupsd should get an response from printer after whole print job is done.

Upstream IPP implementator guide:
https://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf

How to use IPP:
https://www.pwg.org/ipp/ippguide.html

Comment 14 Marek Kašík 2020-03-18 14:55:27 UTC
It seems that the connection is reset from the printer side. I'm looking at this in wireshark now so it will hopefully help. I'll compare it with an Avahi browsed printer from a CUPS server.
Btw, it is HP LaserJet Pro MFP M127fw.

Comment 15 Marek Kašík 2020-03-18 17:51:17 UTC
I see that there is TCP Window Full signalized by wireshark, then there is several TCP ZeroWindow and TCP Keep-Alive and then there is RST (probably the reset).
So the window is small at that time and for some reason the printer reset the connection. I've tried different router here to see whether it could be something with rejecting keep alive messages but it seems not (and the router is not advanced enough to let me configure this).

I've also checked size of this window for the file descriptor given by httpGetFd() but the window doesn't seem 0. But maybe I'm missing something here as I'm not expert over networking.

Btw, I'm not even able to print using ipptool on this printer but the issue I have there it does not accept the document format I'm passing to it. The printer advertises support for "image/urf,application/PCLm,image/jpeg".

Comment 16 Marek Kašík 2020-03-19 12:25:46 UTC
Even if I try "ipptool -v -t ipp://192.168.1.102/ipp/print ./create-job.test" it fails. It creates the job but Send-Document fails with 0 bytes in response.
There is something wrong with the printer probably.
Maybe it works with Air-Print/Bonjour only (but declares itself on _ipp._tcp).

Comment 17 Marek Kašík 2020-03-19 14:52:27 UTC
Created attachment 1671483 [details]
fix for some issues

Hi,

could you try the attached gtk3 patch on top of the one you've tried before? It could solve some issues with printing. Unfortunately, I'm not able to print with it but maybe you will.

Comment 18 Zdenek Dohnal 2020-03-26 06:38:25 UTC
Unfortunately, the patch does not work for me neither. The print dialog is still stuck when I click on the queue, message 'Getting printer information' appears and dialog is loading indefinitely after that.

After clicking on the queue following messages appeared in the terminal:

(evince:334522): GLib-GObject-CRITICAL **: 07:23:04.898: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(evince:334522): GLib-GObject-CRITICAL **: 07:23:34.286: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(evince:334522): Gtk-CRITICAL **: 07:23:56.713: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed


Printing via libreoffice with temporary queue still works.

I'm planning to implement a simple client which will use only CUPS API and check if it works this way too.

If it will work, are you okay if I'll try to implement it in GTK code and possibly reviewing and merging the future patch?

Comment 19 Marek Kašík 2020-03-26 13:47:29 UTC
(In reply to Zdenek Dohnal from comment #18)
> Unfortunately, the patch does not work for me neither. The print dialog is
> still stuck when I click on the queue, message 'Getting printer information'
> appears and dialog is loading indefinitely after that.
> 
> After clicking on the queue following messages appeared in the terminal:
> 
> (evince:334522): GLib-GObject-CRITICAL **: 07:23:04.898: g_object_unref:
> assertion 'G_IS_OBJECT (object)' failed
> 
> (evince:334522): GLib-GObject-CRITICAL **: 07:23:34.286: g_object_unref:
> assertion 'G_IS_OBJECT (object)' failed
> 
> (evince:334522): Gtk-CRITICAL **: 07:23:56.713: gtk_list_store_set_valist:
> assertion 'GTK_IS_LIST_STORE (list_store)' failed

Thank you for trying it. Could you try to print to it with "GTK_DEBUG=printing gtk3-demo" and send me the log? It should tell us how far it got.


> 
> Printing via libreoffice with temporary queue still works.
> 
> I'm planning to implement a simple client which will use only CUPS API and
> check if it works this way too.

We use a specific approach to execute CUPS requests because of non-waiting behaviour so it depends on which API you would use.


> If it will work, are you okay if I'll try to implement it in GTK code and
> possibly reviewing and merging the future patch?

I'm still not sure whether to use this approach. Current implementation should support printing on such printers (except storing of the history) so the current situation is a bug which I would like to fix at first. But if it shows that it is not fixable then we can think about this.

Does "ipptool" with "create-job.test" or "print-job.test" work for you with the printer?

Comment 20 Zdenek Dohnal 2020-05-20 07:50:25 UTC
Created attachment 1690090 [details]
gtk debug

gtk3-demo is a nice tool, thanks! Here are the logs.

My printer doesn't support Send-Document operation (according to get-printer-attributes request):

$ ipptool -tv ipp://NPI42307C.local/ipp/printer get-printer-attributes.test
...
operations-supported (1setOf enum) = Print-Job,Print-URI,Validate-Job,Create-Job,Send-URI,Cancel-Job,Get-Job-Attributes,Get-Jobs,Get-Printer-Attributes
...

so I can test only Print-Job operation:

ipptool -tv ipp://NPI42307C.local/ipp/printer -f <file_to_print> print-job.test

"/usr/share/cups/ipptool/print-job.test":
    Print-Job:
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        printer-uri (uri) = ipp://NPI42307C.local:631/ipp/printer
        requesting-user-name (nameWithoutLanguage) = zdohnal
        document-format (mimeMediaType) = application/pdf
        copies (integer) = 1
    Print file using Print-Job                                           [PASS]
        RECEIVED: 182 bytes in response
        status-code = successful-ok (successful-ok)
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        job-uri (uri) = ipp://NPI42307C.local/ipp/printer/0039
        job-id (integer) = 39
        job-state (enum) = pending
        job-state-reasons (keyword) = none

and the file is printed correctly.

Comment 21 Zdenek Dohnal 2020-05-20 07:51:32 UTC
It looks like an infinite loop in gtk3 according logs. I stopped it after a while.

Comment 22 Petr Sklenar 2020-11-12 12:14:18 UTC
Hi Marek, 
I have new printer 'Canon i-SENSYS MF443dw' and there is the same issue as described here

systemctl stop cups-browsed

lpstat -e
Canon_MF440_Series

lpstat -a
lpstat: No destinations added.

so evince with gtk has queue but its not working ~ 'gathering info about printer' and gray not functional 'print' button.
Libreoffice can print.

Is there anything how can I help to have this bug fixed ?

Comment 23 Marek Kašík 2020-11-13 16:27:51 UTC
Hi Petr,

which version of Fedora do you use?
Could you paste results of "avahi-browse -rt _ipp._tcp" here?

Comment 25 Marek Kašík 2020-11-25 17:29:38 UTC
Hi Petr, could you try whether scratch build of gtk3 from https://koji.fedoraproject.org/koji/taskinfo?taskID=56246930 helps with the issue?

Comment 26 Petr Sklenar 2020-11-26 08:40:45 UTC
no :( unfortunately not

cups-2.3.3-18.fc32.x86_64
gtk3-3.24.23-2.fc32.x86_64
evince-3.36.7-1.fc32.x86_64
firefox-83.0-3.fc32.x86_64


so I did:

systemctl stop cups-browsed; cancel -a; lpadmin -x Canon_MF440_Series;

[root@localhost ~] # lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.

[root@localhost ~] # lpstat -a
lpstat: No destinations added.

[root@localhost ~] # lpstat -e
Canon_MF440_Series

firefox > ctrl +p > click to canon
and there were still 'waiting and waiting and waiting'
'print' is still gray
I could double click to the printer and it generatess log in journal AND print dialog that page is going to be print

[root@localhost ~] # journalctl -f | grep gtk
Nov 26 09:32:03 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed
Nov 26 09:32:25 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed
Nov 26 09:32:29 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed
Nov 26 09:32:37 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed

BUT NOTHING

[root@localhost ~] # lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
[root@localhost ~] # lpstat -e
Canon_MF440_Series
[root@localhost ~] # lpstat -a
lpstat: No destinations added.
[root@localhost ~] # lpq
lpq: Error - no default destination available.
[root@localhost ~] # lpq -a
no entries

Comment 27 Zdenek Dohnal 2020-11-26 13:04:13 UTC
Hi Marek,

I have a slightly different results - in my case loading of attributes ends in a while (though gtk still constantly bombards cupsd with Get-Printers requests on non-existing print queue) but if I click on 'Print', a print job isn't created.

It has the similar behavior as in comment #4.

Comment 28 Marek Kašík 2020-12-03 15:53:21 UTC
Hi,

I've prepared a patch which adds the support for the temporary queues. You can test it in these scratch builds:

https://koji.fedoraproject.org/koji/taskinfo?taskID=56709683 (Fedora 32)
https://koji.fedoraproject.org/koji/taskinfo?taskID=56709673 (Fedora 33)

It is not finished yet since it needs more testing, removing of some redundant code and handling of some corner cases.

Comment 29 Zdenek Dohnal 2020-12-04 09:33:30 UTC
Hi Marek,

thanks for the scratch builds!

I'm able to print via temporary queue now smoothly!

Would you mind attaching the patch once it's finished? I would like to see the implementation for the future reference.

Comment 30 Zdenek Dohnal 2020-12-16 05:42:27 UTC
*** Bug 1908134 has been marked as a duplicate of this bug. ***

Comment 31 Zdenek Dohnal 2020-12-16 05:55:47 UTC
Findings from #1908134:

GTK shouldn't send a 'Delete-printer' request for a print queue which GTK finds via Avahi, unless GTK didn't make the queue permanent afterwards.

It causes useless errors, because the queue doesn't exist in CUPS (because temporary queues aren't saved in cupsd).

Comment 32 Marek Kašík 2021-02-15 10:46:47 UTC
Hi, the change has been merged upstream. You can find it in gtk 3.24.25 and also current master of gtk 4 upstream.

Comment 33 Zdenek Dohnal 2021-02-15 12:59:00 UTC
Thank you for all the work, Marek! It works perfectly!


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