Open MaksVal opened 3 years ago
Having the same problem. Does anybody know how to fix this? Thx!
Hi, and welcome to the Stuck Printer Club! Sorry for the late reply. The log I see here posted by @MaksVal has been cut off, but what was in the deleted part? Was it a lot of repeated back-and-forth CAPT: send A0 E0
's and CAPT: recv A0 E0
's leading nowhere?
If that was the case, it may be a limitation that we don't have a quick fix for. A similar problem has been discussed in agalakhov/captdriver#7.
Long story short, captdriver requires far more "intimate" driver-device communications than CUPS is set up for. The job start sequence is more nuanced than those seen on PCL-like protocols, we can only start the job when the printer makes the right ready signal. The problem is that CUPS has not been returning the correct responses to CAPT status requests on some distros.
We use the CUPS back-channel reads (cups/backend.h/cupsBackChannelRead()
) to poll the printer's status, but it works as we need to only on specific CUPS-libusb configurations. As a result, you can successfully print on some distros (Ubuntu, Fedora) and not others (Raspberry Pi OS/Raspbian).
CUPS was only really designed for use with PCL-like protocols that talk to the printer just to issue jobs and to request printer "status" reports. The "status" herein likely mean high-level things ink levels rather than the really deep stuff like status registers we're dealing with.
I am currently convinced that the only way to implement reliable printing on all operating systems is to create a new driver that talks to the printer directly, only using CUPS to manage jobs and queues. Official drivers use this approach, and printing this way is currently officially recommended. Most networked printers actually do this, but the "driver" is in the printer, not your RPi or PC.
References:
Hmmm so right now I can't print with my Raspberry Pi?
@CookieGMVN @alexpr You might still be able to print from a Raspberry Pi running Ubuntu. In a comment on an older commit (18797c4), someone reported success with printing from a Pi 3 running Ubuntu 19.10.1. I am expecting later versions to work too.
Please be aware that comments discussing causes of the driver failing to print on that commit are somewhat out of date at this point.
Hmmm so right now I can't print with my Raspberry Pi?
There is some issue with Raspberry Pi OS with LBP2900 printer. I recommend installing Ubuntu Server to print to Canon LBP2900 printer using Raspberry Pi. It is working fine for me and one more user also confirmed it here. You can check my working configuration here as well.
Been trying to fight the LBP3000 for a week and am currently trying to document a working process for setting it up.
My current approach is to use a raspberry pi zero with raspbian lite and then compiling this driver to it... however am getting a similar error then this message. Idle - "CAPT: bad reply from printer, expected A2 E1 xx xx xx xx, got A0 E0 0C 00 00 8A"
So if I'm reading correctly, I should be using ubuntu server OS instead? I'll shall give that a shot.
If confirmed, then that should be a pretty critical information to add to the readme under for those who want a raspberry pi print server.
For now, if interested this is how I'm setting up my WIP print server:
Was using 'Raspbian GNU/Linux 11 (bullseye)' (lite version) on a raspberry pi zero
https://gist.github.com/mofosyne/6baab7509ccd93f74d3fa225ea57d75d
=======
Update... looks like I got a raspberry pi zero V1 and ubuntu doesn't work on it... a raspberry pi zero V2 seems rather hard to get these days. GG
2nd Update... on a Ubuntu PC was able to confirm that I could run LBP3000. Ideally however I still would like to get all of this running on a raspberry pi zero V1. (Also cleaned up the LBP3000 compile bash script into https://gist.github.com/mofosyne/c84d23d863454478b4d192b9ca9afd5b in case anyone needs it)
Great work and respect @mofosyne for the build & installation script! (TIL about the shell commands pushd
and popd
, and nice profile pic)
I just want to say that this issue, along with its fellow issues agalakhov#7, agalakhov#36 and mounaiban#14 have been suspected to involve bugs beyond the reach of captdriver. I do not expect this problem to be solvable from captdriver alone, but I would like to be proven wrong, as that would make life easier for all of us.
To summarise our findings as of time of writing:
The CUPS-libusb link is not quite suitable for intimate, full-time bi-directional communications to the standard required by CAPT devices. CUPS is known to replay past responses in a way that looks like symptom of overzealous read buffering. This has caused bad reply errors, or hanging at status checks due to crucial status flags not getting read properly by the backend.
When communicating with a CAPT device, no read buffering should be used, all responses must be fresh.
I am currently convinced that fixing this problem requires either:
ccpd
on your system; this daemon receives print jobs from CUPS and passes print data to the CAPT devices (making use of captdrv
and captmon
).(I'll update this post with links to notable comments related to this issue, we've got a quite a history at this point)
The problem seems to be with the 32-bit (armhf) version of the Raspberry Pi OS. I have been able to print multiple jobs in Canon LBP2900 with the 64-bit (aarch64) Raspberry Pi OS running on Raspberry Pi 4. I have tested it with both the older Bullseye and the latest Bookwork versions.
Printing with captdriver also works with the aarch64 Debian, Manjaro and Ubuntu Linux. Printing with the 32-bit OS works on Ubuntu only. If someone needs to use it for older Pi devices it is recommended to install Ubuntu Linux (armhf).
On armhf (32-bit), I replaced libusb with usblp, but it didn't solve the issue. When using usblp, data is not sent through the CUPS system; instead, direct reading and writing to the file descriptor are done, which rules out issues with CUPS and libusb. I'm currently suspecting it's a problem related to the difference between 64-bit and 32-bit systems. On a 64-bit system, using usblp to read and write data works fine.
After testing, this driver can run normally on Raspberry Pi 3B (with 64-bit Debian installed), but cannot run on 32-bit Debian.
@NullYing did you write your own rasteriser to convert the documents into Hi-SCoA format, and your own port monitor that uses usblp?
Stock Captdriver only works with CUPS as we compress the image inside the CUPS filter, then send the compressed stream to the printer using the filter (see lbp2900_prn.c
). Bypassing CUPS also bypasses the filter. This is contrary to how industry-standard printer drivers work, as filters should not perform communications.
My suspicions are currently against the way CUPS uses libusb. The 64-bit systems are likely using newer versions of libusb that no longer have backchannel read replay bugs that could be triggered by CUPS.
In my case, both 32bit and 64bit work, but i need to power the raspberrypi on first and then power the printer.
After testing, this driver can run normally on Raspberry Pi 3B (with 64-bit Debian installed), but cannot run on 32-bit Debian.
Hi! Thanks for your job. Please, help me. The cups were stuck after status: "Rendering completed". This is the rasbian on raspberry 3 b+ (Raspbian GNU/Linux 10 Linux octopi 5.10.52-v7+ #1441 SMP Tue Aug 3 18:10:09 BST 2021 armv7l GNU/Linux) But your repo was perfect worked on my notebook with ubuntu x86_64.