Support LBP6000/LBP6018

[rezaxdi]

Hey there,

I'm trying to make this driver work with LBP6000 printer, this printer uses same version of CAPT 3.0 as LBP3010 but it seems there should be some differences between the two. Here are list of the things I have done till now :

1. Added LBP6000 to prn_lbp2900.c so I can test the current driver. Driver goes into processing stage for ever. You can see the attahced cups log file.

lbp6000_cups_error_r.log

2. I have also setup wireshark with usbpcap on windows and captured data while printing.

So after comparing captured data with logs that i have from cups I find out that first there is a command that is never sent by cups driver which is a4a00400 but the response from printer is always a4a01400000c00000000000303010dfe00000000 and it never changes no matter what printer is doing so I guess it would be safe to skip it maybe ?

The rest of process completely seems to be same, all commands have same response in both captdriver and windows. What else should I be looking for ?

[mounaiban]

First, welcome and thanks for joining us in getting more printers to work and the log. 😃

I don't have a CAPT 3.0 device at time of writing, so the details you posted are pretty much my best insights into CAPT 3.0 devices for now...

As for your issue, I am suspecting that it's that dreaded CUPS-libusb bug (see also #8) where a previous response is passed back to the driver instead of a fresh one straight from the printer. The driver might be thinking the printer is never ready to print. We're still looking for a workaround for that.

The 0xA4A0 (or 0xA0A4?) command appears to be some kind of autoconfiguration constant, something that I suspect 0xA1A1 (CAPT_IDENT) to also be. Technically, this command should not necessary for successful printing, but on my CAPT 2.1 device (LBP3000), the Canon driver interleaves these commands with 0xA0A8 (CAPT_XSTATUS) when idle as if to pace the call rate to avoid overwhelming the printer by calling 0xA0A8 too frequently.

If you are not already using it, I have made a CAPT dissector for Wireshark which might help you a bit. 🦈

[mounaiban]

I forgot to ask the last time, but which OS are you using? The driver has only been known to work on Ubuntu, Fedora, Debian and Void (see #12) on x86 PCs, and only Ubuntu Server on Raspberry Pi's (see agalakhov#7). I have tested the driver on CentOS once, but I don't remember if it worked more than once.

[rezaxdi]

Hey there, thanks for response. I'm using KDE Neon which is same as Kubuntu 20.04 but with newer KDE. Wasn't aware of that CUPS-libusb bug. I will look forward to intercept the data coming from usb and not from cups-libusb to see if I can see any difference.

[mounaiban]

Hi @rezaxdi, do you still have your LBP6000? I made a branch, 0.1.4.1-register-6000, for testing LBP6000 support. This branch includes a recent fix for the BCD() inline function in src/word.h. It reuses code for supporting the LBP3010.

The BCD() fix was added in commit 1de69f4, and made printing to the LBP3000 from Zorin OS 16.1 possible. I hope the fix works for you too... If you got to test it, please let me know if it worked.

I have not tested the fix on Kubuntu, but I will be doing so shortly.

[rezaxdi]

Sorry for late response. I tested the specified branch and results are same still stuck in processing stage loop. I see something in printer status response which might suggest that CAPT 3.0 has a different printer status response to 0xA0A8 or maybe different command for initialization :

CAPT: printer status P1=1 P2=0 B=1 B0=0 B1=0 nE=1

So P1 flag suggests that there is no paper and B suggest that button is on but none is correct.

[rezaxdi]

Hi again, I checked windows Wireshark log and compared it to cups debug and found 2 commands which were missing between CAPT_GPIO and CAPT_JOB_SETUP stages. Added one of them (0xE0BA) and now my printer prints without any problem. Created a pull request : #19

I don't have the said printer in my location now but I have remote access to it and just did some simple prints with default settings but if any specific test is needed let me know so I can check.

[mounaiban]

Well done and thanks! I have merged it into mounaiban/0.1.4.1-RE branch and successfully compiled the driver from the merged branch without build-breaking regressions 😃

Also which PPD file did you use? Was it CanonLBP-3010-3018-3050.ppd?

At any rate, there's just these two things to do, before I close this issue:

• Update/rename the PPD file, or add notes to the Wiki indicating which PPD to use for the LBP6000
• Test print from the 0.1.4.1-RE branch (preferably a multi-page job)

[rezaxdi]

I tested mounaiban/0.1.4.1-RE branch with a 3 pages pdf file and it was ok. For PPD I used CanonLBP-3010-3018-3050.ppd

[mounaiban]

Looks like we're done with basic LBP6000 support. Thanks again for testing!

I'll close this issue as it concerns just basic support. The next goal would be to produce a more correct CUPS PPD file, but that's for another issue and another day. I'll let you know when we have a plan...

I also just realised that we hit a major milestone: most HiSCoA + CAPT 2.1/3.0 personal printer devices are now supported by the driver. AFAIK, all other unsupported devices that we plan to eventually support are either workgroup printers or CAPT 1.x + SCoA printers. The LBP6200d is an exception, and is a rare example of a duplex-capable personal printer.

I don't think 6200's are common at all, and it might be a long time before we meet someone who still has one.