Rendering completed - Stuck

[balasankarc]

Sometimes, the printing get stuck with the message "Rendering completed". Sometimes it can be fixed by turning the printer off and on. Sometimes, it can be fixed by disabling the printer and enabling it. Often both of them has to be done sequentially to fix the issue.

Ubuntu 14.04 Canon LBP 2900B

[twd2]

I have the same problem.

[is-cs]

First of all thanks for this driver. Its for the first time i was able to setup Google Cloud Print. I'm using Canon-LBP-2900B on my Raspberry Pi running Raspbian Jessie 8. But I'm facing a strange issue, as people have mentioned above. In my case, I'm able to print only once. After i see the "Rendering Complete", further print jobs just dont print, they go from "Processing page 1..." to "Rendering Complete", but printing does not happen. I have to turn off and on the printer again, to fire one more print job, and it becomes useless again. Request you to please fix this issue.

[agalakhov]

Hi, the problem is, I cannot identify the cause. This is not an usual bug in the driver. This is some misinterpretation of the CAPT command set which we don't really know (it is reverse-engineered). Unfortunately I don't have enough information about the CAPT protocol right now to tell why it happens.

I do not own the printer anymore. Hopefully one of the printer owners could do some debugging.

[is-cs]

Hi Galakhov

Its great to hear back from you. I hope the owners will take a look at it. I am a developer myself, and was trying to make sense of the driver code. I could not find WHO is sending this message "Rendering Completed". Its not in the driver code. Although i spotted a couple of messages in the driver code like " bad reply from printer" that i saw on the CUPS webpage a couple times. On Apr 2, 2016 11:45 PM, "Alexey Galakhov" notifications@github.com wrote:

Hi, the problem is, I cannot identify the cause. This is not an usual bug in the driver. This is some misinterpretation of the CAPT command set which we don't really know (it is reverse-engineered). Unfortunately I don't have enough information about the CAPT protocol right now to tell why it happens.

I do not own the printer anymore. Hopefully one of the printer owners could do some debugging.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/agalakhov/captdriver/issues/7#issuecomment-204768759

[missla]

Hi is-cs, have you experienced ant freeze after latest changes of the code? In case could you report the printer state reply.

The message "Rendering Completed" is by CUPS. Keep in mind captdriver is a CUPS filter so it is launched and handle by CUPS.

[Goshik92]

Hi @is-cs ,

How did you manage to run LBP2900 on your Raspberry Pi? I used this guide to install the driver on my Cubieboard 2 with Debian 9, but the printer didn't work at all showing the message "Rendering completed". No manipulations with my printer or driver lead to printing a single page. Did you do anything that is not in the guide above (added compiler options etc)?

[mounaiban]

@agalakhov:

Hi, the problem is, I cannot identify the cause. This is not an usual bug in the driver. This is some misinterpretation of the CAPT command set which we don't really know (it is reverse-engineered).

Don't sweat it, not even Canon has gotten it 100%. The proprietary driver froze frequently (like once out of four jobs) when I was using it on macOS 10.12, and I had to restart or reconnect the printer (LBP 3000) to keep printing. Anyone who manages to solve this problem would have outdone the boss.

[mounaiban]

I just found this today on the CUPS repo: https://github.com/apple/cups/issues/5310

Long story short, someone had the same problem with an HP printer, and found that disabling usblp reattachment in CUPS for the printer solves the stuck printer problem.

I have repeated the same workaround with my LBP3000, and now it takes on job after job without the need to restart or reconnect the printer. This is what you do:

First, identify the vendor-product id of your printer with lsusb or any other capable tool. Let's say my printer has an id of 04a9:1337, as seen on my system:

$ lsusb
...
Bus 001 Device 099: ID 04a9:1337 Canon, Inc. CAPT Device

I would then add the following two lines to $(cups-config --datadir)/usb/org.cups.usb-quirks:

# LBP 3000
0x04a9 0x1337 no-reattach

Remember to su or sudo before editing that file!

Save your edits, and restart or reconnect your printer. The printer should take on additional print jobs without needing more restarts! 😎

I have personally tested this with great success on Xubuntu 18.04.1 (CUPS 2.2.7) and CentOS 8.1.1911 (CUPS 2.2.6) [*2].

As far as my needs are concerned, I think at this point I am getting an experience that rivals or even exceeds what I got out of macOS. Honestly, I haven't got a clue why it worked for me, but I had to try this trick because it sounded like it would work.

Note 1: on most of my systems, $(cups-config --datadir) == /usr/share/cups/ just writing it in that style just in case the directories are different for you...

Note 2: on CUPS 2.2.6, captdriver only works for the LBP 3000 with a previous version of the operations and job preparation routines, prn_lbp2900.c, specifically commit https://github.com/agalakhov/captdriver/commit/216fddba1616546eff73802bab3f12967301dc86

[mounaiban]

Could we have this issue closed now? After some more testing, I think the problem has been largely fixed in 94b2bf2a183e72a0ea68e3a86538d32d9a596889 for LBP2900, or my edit 110697818864f58a8dae5734df019c65b3f8bb6b for LBP3000. If anyone is using these versions or later, please respond to confirm with your printer model if your printer works (also, please ignore my message above and leave the no-reattach USB quirk off).

@Goshik92: if you follow the instructions on https://brain.cdauth.eu/2014/01/16/canon-lbp2900-printer-on-linux/ you might get an error if you compiled captdriver as a normal user. You should see error messages in /var/log/cups/error_log about "insecure filters".

This is because CUPS only runs filters that are owned by root and are read-and-execute-only to everyone else (mode 0755). See https://askubuntu.com/questions/456918/cups-insecure-filter-error-for-lexmark-printer-on-trusty#511351 for details.

[uncleeugene]

Just pulled latest captdriver yesterday to make my LBP2900 work. Same issue, one job printed. I have set no-reattach thing up, not yet tested.

[sbn001]

Just pulled latest captdriver yesterday to make my LBP2900 work. Same issue, one job printed. I have set no-reattach thing up, not yet tested.

Which Linux system / arch are you using? I could get my LPB2900 printer to print multiple pages repeatedly without problems on my Raspberry Pi 3 running Ubuntu server (19.10.1 armhf) and CUPS 2.2.12. I tried with the latest commit b2948baac6bf31ba9c7b374e4959a22fd255fad0 from @mounaiban and it worked without requiring to restart the printer or adding anything to org.cups.usb-quirks.

However, I could not get the same thing to work on a Pi running Raspbian. I am still unable to identify why it did not work in Raspbian. The macs on my home network can now print to LBP2900 via the CUPS running on the Pi (Ubuntu) but I have not been able print from my Windows devices yet. There might be some other issues with communication between CUPS and the Windows system.

Please try compiling the captdriver from https://github.com/mounaiban/captdriver and check if it can print more than once.

[uncleeugene]

I am running Manjaro on x86_64. Thank you for the link, i'll give it a try and report my progress.

[fresun78]

Hi, I have a LBP2900 printer. Have it connected to a rpi 3a+. Installed Raspbian lite today (Raspbian GNU/Linux 10), installed CUPS 2.2.10. Tried install both agalakhov and mounaiban capt driver, also tried editing /usr/share/cups/usb/org.cups.usb-quirks, restarting printer, pause/resume all ended up with same result, "Rendering completed" and nothing printed.

I tried to enable error logging via cupsctl --debug-logging and looked at /var/log/cups/error_log
Not really sure what to look for regarding the "Rendering completed" problem. I found where the "Rendering completed" gets sent:

D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_printer_name[0]=\"Canon_LBP2900\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_printer_uri[0]=\"/printers/Canon_LBP2900\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: time_at_completed[0]=\"novalue\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: time_at_creation[0]=\"Thu Jun 25 18:59:57 2020\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: time_at_processing[0]=\"Thu Jun 25 18:59:57 2020\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_id[0]=\"8\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_state[0]=\"5\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_impressions_completed[0]=\"0\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_k_octets[0]=\"1\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_printer_state_message[0]=\"Rendering completed\" D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetVariable: THISURL=\"/jobs/\" D [25/Jun/2020:19:00:02 +0100] [Client 1] CGI data ready to be sent. D [25/Jun/2020:19:00:02 +0100] [Client 1] con->http=0x16f9da8 D [25/Jun/2020:19:00:02 +0100] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_CHUNKED, dat a_remaining=0, response=(nil)(), pipe_pid=10890, file=21 D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for CGI data. D [25/Jun/2020:19:00:02 +0100] [Client 1] con->http=0x16f9da8 D [25/Jun/2020:19:00:02 +0100] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_CHUNKED, dat a_remaining=0, response=(nil)(), pipe_pid=10890, file=21 D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for CGI data. D [25/Jun/2020:19:00:02 +0100] [Client 1] CGI data ready to be sent. D [25/Jun/2020:19:00:02 +0100] [Client 1] con->http=0x16f9da8 D [25/Jun/2020:19:00:02 +0100] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_CHUNKED, dat a_remaining=0, response=(nil)(), pipe_pid=10890, file=21 D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for CGI data. D [25/Jun/2020:19:00:02 +0100] [Client 1] con->http=0x16f9da8 D [25/Jun/2020:19:00:02 +0100] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_CHUNKED, data_remaining=0, response=(nil)(), pipe_pid=10890, file=21 D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for CGI data. D [25/Jun/2020:19:00:02 +0100] [Client 4] HTTP_STATE_WAITING Closing for error 32 (Broken pipe) D [25/Jun/2020:19:00:02 +0100] [Client 4] Closing connection. D [25/Jun/2020:19:00:02 +0100] cupsdSetBusyState: newbusy="Active clients and printing jobs", busy="Active clients and printing jobs" D [25/Jun/2020:19:00:02 +0100] PID 10890 (/usr/lib/cups/cgi-bin/jobs.cgi) exited with no errors. D [25/Jun/2020:19:00:02 +0100] [Client 1] CGI data ready to be sent. D [25/Jun/2020:19:00:02 +0100] [Client 1] con->http=0x16f9da8 D [25/Jun/2020:19:00:02 +0100] [Client 1] cupsdWriteClient error=0, used=0, state=HTTP_STATE_GET_SEND, data_encoding=HTTP_ENCODING_CHUNKED, data_remaining=0, response=(nil)(), pipe_pid=10890, file=21 D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for CGI data. D [25/Jun/2020:19:00:02 +0100] [Client 1] Sending 0-length chunk. D [25/Jun/2020:19:00:02 +0100] [Client 1] Flushing write buffer. D [25/Jun/2020:19:00:02 +0100] [Client 1] New state is HTTP_STATE_WAITING D [25/Jun/2020:19:00:02 +0100] [Client 1] Waiting for request. D [25/Jun/2020:19:00:02 +0100] cupsdSetBusyState: newbusy="Printing jobs", busy="Active clients and printing jobs"

After that I had a lot of repeated messages (identical as below)

I [25/Jun/2020:19:00:07 +0100] Expiring subscriptions... D [25/Jun/2020:19:00:07 +0100] [Job 8] CAPT: send A0 E0 04 00 D [25/Jun/2020:19:00:07 +0100] [Job 8] CUPS_SC_CMD_DRAIN_OUTPUT received from driver... D [25/Jun/2020:19:00:07 +0100] [Job 8] Read 4 bytes of print data... D [25/Jun/2020:19:00:07 +0100] [Job 8] Wrote 4 bytes of print data... D [25/Jun/2020:19:00:07 +0100] [Job 8] CAPT: waiting for 6 bytes D [25/Jun/2020:19:00:07 +0100] [Job 8] Read 6 bytes of back-channel data... D [25/Jun/2020:19:00:07 +0100] [Job 8] CAPT: recv A0 E0 06 00 88 00

I also checked

dmesg | grep usblp [ 4.758896] usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04A9 pid 0x2676 [ 4.759180] usbcore: registered new interface driver usblp [ 14.653722] usblp0: removed [ 111.207228] usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04A9 pid 0x2676 [ 177.112430] usblp0: removed

So it turns out the /dev/usb/lp0 appears for a very short time and then gets removed again. I tried lpadmin -p Canon_LBP2900 -o usb-no-reattach-default=true Now the /dev/usb/lp0 device appears (and remains).

Now trying to print again moves past the "Rendering completed", but halts with a new error.

lpstat -p printer Canon_LBP2900 is idle. enabled since Thu Jun 25 20:43:20 2020 CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got A1 A1 38 00 00 0B

From /var/log/cups/error_log

D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: rastertocapt: start job D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: send A1 A1 04 00 D [25/Jun/2020:20:43:20 +0100] [Job 12] Read 4 bytes of print data... D [25/Jun/2020:20:43:20 +0100] [Job 12] Wrote 4 bytes of print data... D [25/Jun/2020:20:43:20 +0100] [Job 12] CUPS_SC_CMD_DRAIN_OUTPUT received from driver... D [25/Jun/2020:20:43:20 +0100] [Job 12] Read 6 bytes of back-channel data... D [25/Jun/2020:20:43:20 +0100] [Job 12] Read 50 bytes of back-channel data... D [25/Jun/2020:20:43:20 +0100] [Job 12] Rendering completed D [25/Jun/2020:20:43:20 +0100] [Job 12] PID 1795 (/usr/lib/cups/filter/gstoraster) exited with no errors. D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: output already empty, not drained D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: waiting for 6 bytes D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: waiting for 50 bytes D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: recv A1 A1 38 00 00 0B 31 2A 01 01 F0 FF 40 00 04 00 D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 41 00 01 00 D0 02 00 00 6F 08 00 00 E4 0D 00 00 D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 00 00 00 00 FA 02 00 00 F6 04 00 00 28 3C 32 32 D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 58 02 58 02 15 03 02 02 D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: send A0 E0 04 00 D [25/Jun/2020:20:43:20 +0100] [Job 12] Read 4 bytes of print data... D [25/Jun/2020:20:43:20 +0100] [Job 12] CUPS_SC_CMD_DRAIN_OUTPUT received from driver... D [25/Jun/2020:20:43:20 +0100] [Job 12] Wrote 4 bytes of print data... D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: waiting for 6 bytes D [25/Jun/2020:20:43:20 +0100] [Job 12] Set job-printer-state-message to "CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got A1 A1 38 00 00 0B", current level=ERROR

After this the /dev/usb/lp0 got removed again

[ 1263.347568] usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 6 if 0 alt 0 proto 2 vid 0x04A9 pid 0x2676 [ 1411.672350] usblp0: removed

And restarting the print job gets stuck at "Rendering completed".

[mounaiban]

@fresun78 thanks for your feedback. Try reverting to 216fddb with git checkout, and see if you can print.

Please note that printing support was a lot less complete at the time of the commit; while it was the last commit known to work on Raspbian with the LBP2900, at that stage you had to restart the printer between jobs (among other limitations).

At time of writing, I believe this issue is due to a failure to correctly communicate with the LBP2900 to obtain a job number (see lbp_2900_job_prologue() in prn_lbp2900.c). I have mentioned this earlier in the issue tracker in my fork: https://github.com/mounaiban/captdriver/issues/3#issuecomment-623868567

I suspect that the CAPT_JOB_BEGIN command has been incorrectly issued due to a lack of understanding of the printer's behaviour. You can also have a look at capt-status.c to see how the status checks are done. If you notice anything we are doing wrong, please let us know.

In the meantime, I am thinking of overriding the job number with the one provided by CUPS. This is a return to how things were done in 216fddb, except that the job number will be allowed to move beyond 1. Hopefully, this would allow you to work around the bug that has been preventing the LBP2900 from printing.

[fresun78]

@mounaiban You're right, I did a checkout of 216fddb and it is working (1 print job). I haven't had time to test too much, just printed one test page and it was working without any problems. What is the print job no. used for? I read your comment in the other issue tracker, that the filter gets reset for every print job. I suppose for a persistent tracking and assigning of self-generated print job no. some IPC with a background process or just writing to a text file would be possible solutions? The best I suppose would be to find out how LBP2900 actually communicates and sends job no. The (reverse-engineered) communication protocol is working for other LBP printers but not LBP2900?

[agalakhov]

I did the original reverse-engineering with LBP2900. It worked but was quite incomplete. Then others continued it with other models. It could be that LBP2900 had some bug that was fixed in later models and that it needs some unknown workaround. I did not manage to restore the printer's original state after printing.

Unfortunately I don't own any LBP printers anymore so I can't help further.

[mounaiban]

@fresun78: Just realised that job numbers generated by CUPS are easy to read. Recall that there are six arguments sent to a filter, and the first argument is the job ID, so I might just shove main()'s argv[1] in there. Hopefully, we won't need to write any extra files...

The job number is an identifier that must be assigned to every job received by the printer. I think the printer uses it to tell when the last job ends and the next one begins. Every next job will need a different number for the printer. While I feel that those numbers are not quite needed for personal printers like the LBP2900 and 3000, those may be useful on network-capable, multi-user printers like the LBP6300dn.

I am trying to understand the relationship between the three or so status check commands @agalakhov discovered for the LBP2900. Based on Wireshark studies I have done so far, I am suspecting that the printer cannot read and write the status registers at the same time, so reading the extended status too much (which capt_wait_xready_only() in capt-status.c might be doing) may be locking up the printer. More studies are needed to confirm this.

[nerk]

@mounaiban @agalakhov Thanks a lot for the work! I was not expecting that anybody was still working on this. Where is the fun in just buying something new and dump this otherwise perfectly working printer?

[mounaiban]

Hi again, I have pushed a new branch 0.1.4-dev-use-cups-job-id on my fork, containing a workaround of the kind I have been talking about above. For those using the LBP2900 on Raspbian, please test and let me know if it gets your printer working.

@nerk I love Canon printers. They're engineering masterpieces that have fallen victim to some very poor decisions regarding the software architecture on those fine machines. Canon needed HP to do its mechanisms justice with superior firmware and drivers.

[agalakhov]

BTW, many HP printers are mechanically identical to HP ones. But HP does not have any software problems.

[nerk]

@mounaiban I tried your new branch on 32-bit Raspberry PI OS (Raspbian) on my Pi 4 and the problem is still the same, unfortunately. I also noticed that after the first print job, lpinfo -v no longer show the Canon printer URI. I have to pull and reconnect the USB cable to make it appear again.

[mounaiban]

@nerk Did you manage to print some pages, or did the printer freeze before the first page?

At any rate, this looks like the end of the road for my hacks... 🤔 We will have to look much deeper to get the printers to work properly under Raspbian.

[nerk]

@mounaiban Thanks for your work. Don't sweat it. Maybe, I'll try to investigate and debug the code - one day. I don't think I am smart enough, though. It has always been PITA to get this printer running under Linux, even with the official CANON drivers. They are no longer compatible with recent versions of CUPS either.

I actually tried all the different ways I found on the Web to get this printer running on 64-bit Linux and recent Linux versions, but without any luck. In the end, I resorted in installing Ubuntu 14.04 and the official CAPT drivers in a LXC container, running as a guest on my desktop machine. I documented the process in case anybody needs it. It proved to be a pretty reliable setup.

Having everything on the Pi would be much nicer, of course.

[nerk]

@mounaiban To answer your actual question: The printer froze before the first page. One thing I might try is to use the version on your branch on my 20.04 Ubuntu machine and compare the data sent over USB with the Raspi. Maybe it's a byte ordering problem.

[nerk]

@sbn001 If you still cannot print from Windows, maybe the solution is to use a particular Windows driver. Have a look at the end of https://github.com/nerk/canon-capt-installation.

[sbn001]

@sbn001 If you still cannot print from Windows, maybe the solution is to use a particular Windows driver. Have a look at the end of https://github.com/nerk/canon-capt-installation.

Thank you for the information. I could successfully print from Windows 10 devices after installing Bonjour Print Services from Apple. Windows recognized the printer shared from CUPS and worked independent of the driver. More on that available in this discussion.

The official drivers from Canon works well on Intel x86 systems (both 32 bit and 64 bit). The only problem is with the ARM devices which are not officially supported by Canon.

[mounaiban]

Hello again, and Merry Christmas! :christmas_tree: :santa: For those of you who had trouble getting your LBP2900s to start: I have been reading the CUPS logs that you have shared. I am now suspecting CUPS for incorrectly repeating a previous reply to a status check. If we could somehow get CUPS to 'flush' all previous responses and get a fresh one from the printer, we might be able to get the print job running.

Here's a closer look at your logs: @fresun78, :printer:LBP2900 https://github.com/agalakhov/captdriver/issues/7#issuecomment-649788191

D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: recv A1 A1 38 00 00 0B 31 2A 01 01 F0 FF 40 00 04 00
D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 41 00 01 00 D0 02 00 00 6F 08 00 00 E4 0D 00 00
D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 00 00 00 00 FA 02 00 00 F6 04 00 00 28 3C 32 32
D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: 58 02 58 02 15 03 02 02
D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: send A0 E0 04 00
D [25/Jun/2020:20:43:20 +0100] [Job 12] Read 4 bytes of print data...
D [25/Jun/2020:20:43:20 +0100] [Job 12] CUPS_SC_CMD_DRAIN_OUTPUT received from driver...
D [25/Jun/2020:20:43:20 +0100] [Job 12] Wrote 4 bytes of print data...
D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: waiting for 6 bytes
D [25/Jun/2020:20:43:20 +0100] [Job 12] Set job-printer-state-message to "CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got A1 A1 38 00 00 0B", current level=ERROR

The driver is seen here requesting CAPT_CHKSTATUS (big endian: 0xE0A0) right after a CAPT_IDENT (0xA1A1). However, CUPS seems to be replaying the response to CAPT_IDENT as seen on the last line (scroll the log clipping to the right if it is out of view). I am singling out the CUPS-libusb connection here, as this bug does not seem to affect libusb 1.0.23. Systems such as Ubuntu 19.10 (or later) use newer versions of libusb. Raspbian, at time of writing, uses libusb 1.0.22.

Meanwhile, this came up pretty often in the logs: @sbn001, :printer: LBP2900 https://github.com/mounaiban/captdriver/issues/3#issuecomment-621758454

D [24/Apr/2020:16:29:19 ] [Job 4] CAPT: send A0 E0 04 00
D [24/Apr/2020:16:29:19 ] [Job 4] Read 4 bytes of print data...
D [24/Apr/2020:16:29:19 ] [Job 4] CUPS_SC_CMD_DRAIN_OUTPUT received from driver...
D [24/Apr/2020:16:29:19 ] [Job 4] Wrote 4 bytes of print data...
D [24/Apr/2020:16:29:19 ] [Job 4] CAPT: waiting for 6 bytes
D [24/Apr/2020:16:29:19 ] [Job 4] Read 6 bytes of back-channel data...
D [24/Apr/2020:16:29:19 ] [Job 4] CAPT: waiting for 6 bytes
D [24/Apr/2020:16:29:19 ] [Job 4] Read 6 bytes of back-channel data...
D [24/Apr/2020:16:29:19 ] [Job 4] CAPT: recv A0 E0 0C 00 00 8A 00 00 0F 00 00 00
I [24/Apr/2020:16:29:20 ] Expiring subscriptions...

# this just repeats itself but the printer doesn't print

Inferring from the previous example, CUPS might be stuck replaying the first CAPT_CHKSTATUS reply since the job started. The response contains a flag, CAPT_FL_XSTATUS_CHNG that is raised when the printer's status registers have been updated, indicating the right time to request a more detailed status report. But in replaying old responses, the flag is never updated, causing the driver to be stuck in the flag check loop.

See also:

• SPECS: https://github.com/agalakhov/captdriver/blob/master/SPECS
• capt-status.c, capt-status.h
• https://github.com/mounaiban/captdriver/commit/18797c4c8edf916add31c09a2c527cf284021e14#r38560725

[mmlion]

Hello and Happy New Year!

Thank you for your great work! I tried to run lbp300 on Raspbian (debian 10) for rpi4. Unfortunately, both agalakhov/captdriver and 0.1.4-dev-use-cups-job-id do not work (no pages are printed). Cups stuck at "Rendering completed". Message "CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got" appears when I switch off the printer and this message does not disappear when I switch on the printer Adding "no-reattach" to org.cups.usb-quirks does not help.

When try to print a test page I get

$ cat /var/log/cups/error_log W [01/Jan/2021:18:44:25 +0000] [Job 11] support of LBP3000 is experimental

After 5 minutes of waiting, when I switch the printer off I get

W [01/Jan/2021:18:44:25 +0000] [Job 11] support of LBP3000 is experimental E [01/Jan/2021:18:50:50 +0000] [Job 11] Не удается отправить данные на принтер. (="Could not send data to the printer") E [01/Jan/2021:18:50:52 +0000] [Job 11] CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got

Switching the printer on does not add anything to error_log

I'm really interesting in helping with the driver testing/coding, if it possible.

[mounaiban]

@mmlion Hi, and welcome to the Stuck Printer Club! I wish I had a solution for this right now, but it is going to be a while before some progress is made on this front. I am currently trying to figure out a way to work around the response replay problem on the LBP3000 using libusb directly, after failing to find a way using CUPS' limited backend commands.

Maybe try building newer versions of libusb (1.0.23 or later) and CUPS from source?

[mmlion]

I've tried libusb-1.0-0_1.0.24-2_armhf from debian 11 with no luck (no-reattach also did not help). CUPS seems to be much harder to install (due to a lot of dependencies). Do you think it can help? If yes, I may try just debian 11 to try CUPS 2.3.3 ...

[mounaiban]

If a newer version of libusb doesn't work with the same version of CUPS, this implicates CUPS as the source of the problem, specifically the way CUPS handles communications with the devices.

There are two (untested) workarounds I can think about at the moment for 10.6:

1. Build CUPS 2.3.3 from source, but pair it up with libusb 1.0.22
2. Build CUPS 2.3.3 with libusb 1.0.23

@nerk had mentioned earlier in this issue that there could be a "byte ordering problem". I have also been wanting to investigate this, It would involve using Wireshark to capture commands sent to the printer on three different configurations:

i. Captdriver on systems where it doesn't print (e.g. Raspbian, ZorinOS 32-bit) ii. Captdriver on system where it prints (e.g. Ubuntu 19.10) iii. Official driver on Windows or macOS

The results would then be compared to see if bytes have been swapped on the outgoing commands. I really hope this isn't the case, because if it was, the workaround could be messy... :scream:

[agalakhov]

Byte swaps are very unlikely.

Likely is that CUPS has somehow broken back channel. AFAIK the only driver really relying on this channel is our one. If, for instance, the back channel is buffered (that is, data come in large chunks and are delayed until the chunk is full), we'll get a stuck printer. If CUPS silently introduced such kind of buffering (maybe even by mistake), no one but us will complain.

Official driver completely replaces a large part of CUPS and thus does not depend on back channel functionality.

[mmlion]

So I've made cups 2.3.3 from source and try it with capt-driver (previously built for cups 2.3.1). Two times actually, and the result was slightly different (I'm not sure why).

First attempt: cups was unable to add the printer with the following in systemlog

Jan 17 14:29:43 kas kernel: [   89.223471] usblp0: removed
Jan 17 14:29:43 kas kernel: [   89.236924] usblp 1-1.4:1.0: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04A9 pid 0x266A

Second attempt (after I removed all cups packages clear all cups deb packages and reinstall them): cups was also unable to add the printer but gave no errors. Also lpadmin gave me "success", but the printer does not appear.

I think the reason is the following. I've tried to recompile captdriver with cups 2.3.3 installed, but gcc gave

$ gcc -std=c99 -Wall -Wextra -pedantic  -g -O2   -o rastertocapt rastertocapt.o capt-command.o capt-status.o generic-ops.o printer.o paper.o hiscoa-common.o hiscoa-compress.o prn_lbp2900.o -lcups
/usr/bin/ld: rastertocapt.o: in function `do_print':
/home/lion/help/lbp3000/captdriver-master/src/rastertocapt.c:185: undefined reference to `cupsRasterOpen'
/usr/bin/ld: /home/lion/help/lbp3000/captdriver-master/src/rastertocapt.c:195: undefined reference to `cupsRasterReadHeader2'
/usr/bin/ld: rastertocapt.o: in function `compress_page_data':
/home/lion/help/lbp3000/captdriver-master/src/rastertocapt.c:121: undefined reference to `cupsRasterReadPixels'
/usr/bin/ld: /home/lion/help/lbp3000/captdriver-master/src/rastertocapt.c:147: undefined reference to `cupsRasterReadPixels'
/usr/bin/ld: rastertocapt.o: in function `do_print':
/home/lion/help/lbp3000/captdriver-master/src/rastertocapt.c:271: undefined reference to `cupsRasterClose'

It seems very strange, since file /usr/include/cups/raster.h (on my rpi) does have these functions defined... May be I did something wrong? (I installed cups 2.3.3 from source by usual ./configure + make + make install hoping it will replace 2.3.1, and i think it does. May be I should also install the corresponding libcups2-dev from source?)

[agalakhov]

-lcupsimage is missing at the compiler command line.

[nerk]

@mounaiban @agalakhov Byte swapping problem was just a wild guess. However, wasn't somebody sucessfully running the driver under Ubuntu on a Raspi? That would rule out byte ordering as the reason.

[mmlion]

@agalakhov Yes, this helps, thanks. rastertocapt compiles without problems, but still cups 2.3.3 was unable to add the printer. cupsd felt down every time after lpadmin -p. Here are logs:

$ cat /var/log/systemd
Jan 17 18:40:59 kas systemd[1]: cups.service: Main process exited, code=killed, status=11/SEGV
Jan 17 18:40:59 kas systemd[1]: cups.service: Failed with result 'signal'.
Jan 17 18:40:59 kas systemd[1]: cups.service: Service RestartSec=100ms expired, scheduling restart.
Jan 17 18:40:59 kas systemd[1]: cups.service: Scheduled restart job, restart counter is at 1.
Jan 17 18:40:59 kas systemd[1]: Stopping Make remote CUPS printers available locally...

$ cat /var/log/cups/access_log
localhost - - [17/Jan/2021:18:40:59 +0000] "POST / HTTP/1.1" 200 21589 CUPS-Get-PPD -
localhost - - [17/Jan/2021:18:40:59 +0000] "POST /admin/ HTTP/1.1" 401 21686 CUPS-Add-Modify-Printer successful-ok

/var/log/cups/error_log was empty

---

@mounaiban @agalakhov Byte swapping problem was just a wild guess. However, wasn't somebody sucessfully running the driver under Ubuntu on a Raspi? That would rule out byte ordering as the reason.

@agalakhov @mounaiban @nerk Is it worth to try ubuntu on rpi instead of debian 10? 20.10 has cups 2.3.3...

[agalakhov]

Most RPi distributions have the same little-endian byte ordering as x86. The driver itself was developed with byte-order in mind so byte-order problems are extremely unlikely. I never cast words to bytes in the driver.

[agalakhov]

@mmlion This is "Segmentation fault" in CUPS (signal 11). Should never happen and does not depend on the driver. This is a CUPS bug.

[sbn001]

Hello,

I had been doing some testing with printing on the LBP 2900 printer from Raspbian. While testing the printer could not print normally and got stuck in ' Processing - "Rendering completed" ' message. It could not print even after restart the printer or unplugging and re-plugging the USB cable and pressing "Release Job" in the CUPS remote web interface.

In the processing of testing, I discovered that the LBP 2900 printed the stuck print job after undertaking following steps:

1. Unplug the USB cable (printer state changes to ' held since __ "Unable to send data to printer." ')
2. Connect printer to a Windows device
3. Print something from the Windows device
4. Reconnect the printer back to the Raspberry Pi
5. Click "Release Job" button in the CUPS remote web interface (https://192.168.86.18:631/printers/Canon_LBP2900)

The printer was able to print a single page next time as well by following the above process again.

I think that printing with captdriver is stuck because the printer (or the driver) is expecting some response / reply which has not been met by the driver. The stuck printer seems to be refreshed after printing from Windows or some other capable device and once I connected the printer back to the Raspberry PI, it printed without errors and got stuck again. I tried printing with the current master (commit: f2077b6 version: 0.1.3) and also from the fork maintained by @mounaiban (commit: 5cefa27 version: 0.1.4-m5) but got similar results.

I don't know if this information would be useful in resolving the issue. I can share the cups error logs if those can be helpful. I will also continue testing by upgrading the libusb-1.0-0/stable 2:1.0.22-2 armhf to libusb-1.0-0/testing 2:1.0.24-3 armhf from the Raspbian repositories and share the printing performance.

My current configuration is as shown below:

Raspbian GNU/Linux 10 (buster) 5.10.17-v7l+ #1421 armv7l
Raspberry Pi 4 Model B Rev 1.2
CUPS 2.2.10

libusb-1.0-0/stable, now 2:1.0.22-2 armhf
libusb-1.0-0-dev/stable 2:1.0.22-2 armhf

Canon Inc LBP2900/LBP3010 r2c, 0.1.3 (https://github.com/agalakhov/captdriver.git master)
and
Canon LBP2900/LBP3000 r2c, 0.1.4-m3 (https://github.com/mounaiban/captdriver.git master)

[sbn001]

@agalakhov @mounaiban @nerk Is it worth to try ubuntu on rpi instead of debian 10? 20.10 has cups 2.3.3...

I have been printing wirelessly from my Windows, Mac, Android and iOS devices to the Canon LBP2900 printer for some time now, using a Raspberry Pi 3B running Ubuntu 20.04.2 LTS. It has been working (almost) flawlessly in printing multiple pages, multiple times from different devices without getting stuck.

@mmlion I think it would be sensible to install Ubuntu Server (https://ubuntu.com/download/raspberry-pi) on a Raspberry Pi, until the Raspbian issue gets solved, to print wirelessly to your old Canon printer. I am sharing my current working configuration below:

Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1035-raspi armv7l)
Raspberry Pi 3 Model B Plus Rev 1.3 (or any other Pi model)
CUPS 2.3.1
libusb-1.0-0/focal,now 2:1.0.23-2build1 armhf

https://github.com/mounaiban/captdriver
Commit: d920628
Driver: CNLB2K9.ppd
Driver Version: 0.1.4-m5
Make & Model: Canon LBP2900/LBP3000 r2c, 0.1.4-m5

[Swyter]

I have also been having a similar issue when printing through CUPS with my MP240 on Arch Linux x86_64 for a few months, previously (since 2015 and until today) I was using the official Canon driver, which had the exact same getting-stuck-after-printing-right-up-until-the-end problems so I tried switching to the open-source counterpart today, so that's why I suspect that this is a somewhat recent USB/libusb-related issue. I have been printing occasionally from Linux for years.

Printing on Windows 8 through the official drivers using the same setup worked fine, and the first page printed on Linux after rebooting from printing on Windows seemed to also work and finish correctly, I believe.

In my case if I wait for around 15 minutes the printer finishes correctly, it just gets stuck in place 3/4 into the page for entire minutes, moving the printing head a bit from time to time. If I disconnect the USB connection between the printer and the computer it stops and finishes. So, to me, it seems like the printer is waiting for some kind of USB response.

---

I have tried @mounaiban's solution above and it seems like adding the quirk (with the proper VID/PID) via sudo gedit $(cups-config --datadir)/usb/org.cups.usb-quirks does the trick for me:

# Canon, Inc. MP240 Printer
0x04a9 0x1732 unidir

Adding no-reattach doesn't seem to hurt, but it works without it in my case, so I'm guessing that unidir is the one doing the work here:

0x04a9 0x1732 no-reattach unidir

Anyway, with this I can use my printer again, so thanks for all the information in this thread. I'll try to add the quirk officially.

[mounaiban]

@Swyter Glad that you were able to solve an issue with a Canon inkjet using info in the issues section of a seemingly unrelated driver. :angel:

On the other hand, I wish there was a means of flushing the backchannel buffer or a similar feature in CUPS that would solve this stuck printer issue with captdriver. I think it's highly unlikely that such a feature would be implemented though.

Apple probably thinks we should rewrite our driver as a Printer Application and handle communications with the printer with libusb.

[senthilmurukang]

@sbn001 Thanks for your suggestion to use Ubuntu Server OS on a Raspberry Pi. This repo(https://github.com/mounaiban/captdriver) worked for me.

[mounaiban]

Just letting you all know, a fix for BCD() in src/word.h, originally written by @ra1nst0rm3d, has been pushed to my 0.1.4.1-RE branch as of https://github.com/mounaiban/captdriver/commit/1de69f4dc2e375de1139a905e7772a71120f774e. I'm thinking this may fix this issue.

I have been able to print to an LBP3000 from ZorinOS Education 16.1 (x86_64) consistently, and I invite all of you to test it out, (especially on Raspbian/Raspberry Pi OS, and I hope it works for you.

If you have recently updated or cloned my fork, please remember to use the --rebase option with git pull as I have recently made a forced push on this branch. Remember to git checkout 0.1.4.1-RE before you start the compilation process!

[nerk]

@mounaiban Ooops, maybe I gave up too early because I finally dumped my old Canon printer a few weeks ago. I switched to a HP monochrome Laser printer, which is working out of the box without any pain. However, the mechanical build quality of the old Canon printer really seems to be superior. I wish everybody success in keeping the Canons working!

[mounaiban]

Thanks @nerk for being with us anyway, I almost gave up on my printer too trying to find a fix for this issue. It didn't help that a shop in my city was, and still is, selling WiFi-capable monochrome printers for peanuts.

I am beginning to actually like the CAPT protocol in a retrocomputing kind of way. The engineers at Canon have my respect for trying to implement a printer device that was supposed to have practically unlimited memory, despite how much of a mess it turned out.

CAPT is a relic of a time when it was still a luxury to have a printer that had enough on-board memory and computing power to take on random PDFs and poorly-optimised Word documents in their entirety.

[sbn001]

Just tested my Canon LBP2900 with 0.1.4.1-RE branch from @mounaiban on Raspberry Pi OS (bullseye) but the issue is still the same. Tried adding

# Canon LBP2900
0x04a9 0x2676 no-reattach

as well but no sucsess in printing.

processing since
Mon Sep 26 15:43:35 2022 
"Rendering completed"

The error log is as follows

D [26/Sep/2022:15:48:14 +0545] [Job 15] Read 6 bytes of back-channel data...
D [26/Sep/2022:15:48:14 +0545] [Job 15] CAPT: waiting for 6 bytes
D [26/Sep/2022:15:48:14 +0545] [Job 15] Read 6 bytes of back-channel data...
D [26/Sep/2022:15:48:14 +0545] [Job 15] CAPT: recv  A0 E0 0C 00 04 8A 00 00 0F 00 00 00
D [26/Sep/2022:15:48:15 +0545] [Job 15] CAPT: send  A0 E0 04 00
D [26/Sep/2022:15:48:15 +0545] [Job 15] Read 4 bytes of print data...
D [26/Sep/2022:15:48:15 +0545] [Job 15] CUPS_SC_CMD_DRAIN_OUTPUT received from driver...
D [26/Sep/2022:15:48:15 +0545] [Job 15] Wrote 4 bytes of print data...
D [26/Sep/2022:15:48:15 +0545] [Job 15] CAPT: waiting for 6 bytes
I [26/Sep/2022:15:48:15 +0545] Expiring subscriptions...

[copetogo]

I just found this today on the CUPS repo: apple/cups#5310

Long story short, someone had the same problem with an HP printer, and found that disabling usblp reattachment in CUPS for the printer solves the stuck printer problem.

I have repeated the same workaround with my LBP3000, and now it takes on job after job without the need to restart or reconnect the printer. This is what you do:

First, identify the vendor-product id of your printer with lsusb or any other capable tool. Let's say my printer has an id of 04a9:1337, as seen on my system:

$ lsusb
...
Bus 001 Device 099: ID 04a9:1337 Canon, Inc. CAPT Device

I would then add the following two lines to $(cups-config --datadir)/usb/org.cups.usb-quirks:

# LBP 3000
0x04a9 0x1337 no-reattach

Remember to su or sudo before editing that file!

Save your edits, and restart or reconnect your printer. The printer should take on additional print jobs without needing more restarts! 😎

I have personally tested this with great success on Xubuntu 18.04.1 (CUPS 2.2.7) and CentOS 8.1.1911 (CUPS 2.2.6) [*2].

As far as my needs are concerned, I think at this point I am getting an experience that rivals or even exceeds what I got out of macOS. Honestly, I haven't got a clue why it worked for me, but I had to try this trick because it sounded like it would work.

Note 1: on most of my systems, $(cups-config --datadir) == /usr/share/cups/ just writing it in that style just in case the directories are different for you...

Note 2: on CUPS 2.2.6, captdriver only works for the LBP 3000 with a previous version of the operations and job preparation routines, prn_lbp2900.c, specifically commit 216fddb

Hi i am a novice with linux commands. can you tell me the command to open and edit the file you mentioned above on mac terminal