Taken at the tail end of the Florida Flow Fest.
In the past I've written about the particularly poor level of support for Mitsubishi printers under Linux. In the past couple of months, that has changed substantially, although not due to any action or assistance on Mitsubishi's part.
Gutenprint 5.2.11 had usable support for the CP-9550DW and CP-9550DW-S models, including an intelligent backend that handled the printer communications. However, the rest of the CP-9xxx family wasn't supported.
The 5.2.12 release of Gutenprint will support most of the CP-9xxx family. This includes a considerable amount of work on the backend, genericizing it so that the other models can be cleanly handled. This was a rather disruptive change, so it's possible the formerly-working CP-9550 family has regressed. Beyond that, the newly-supported models need testing to confirm that everything functions as expected.
Here is the list of all models affected by this development:
- CP-9550DW (previously working, needs retesting)
- CP-9550DW-S (previously working, needs retesting)
- CP-9600DW (confirmed working)
- CP-9800DW-S (confirmed working!)
Also, I still need testers for the following models:
- DNP DS80DX
- Sony UP-CR10L (aka DNP DS-SL10)
- Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S, CP-D80DW, and CP-D90DW (plus their -S variants!)
- Fujifilm ASK-300
- Sinfonia CHC-S1245/E1 and CHC-S6245/CE1
- Kodak 7000/7010/7015 and 8810
If anyone reading this has access to one or more of these printers, please drop me a line!
UPDATE 10/27: There were definitely some bugs to be had, but now the CP-9600DW and CP-K60DW-S are now confirmed working!
UPDATE 11/18: After fixing a couple of bugs, the CP-D70DW and CP-D80DW are now confirmed working.
Over the past few years, I've written a lot about the various members of the Mitsubishi CP-D70 family of printers, and how they were utterly worthless under Linux.
These printers are unusual in that they required the host computer to perform perform gamma correction and thermal compensation to the image data in order to generate sane output. (If this sounds familiar, it's because the Sinfonia CS2 was similarly afflicted). This relied on unknown, proprietary algorithms only implemented within Mitsubishi's drivers.
To make along story short, I've been attempting to reverse engineer those algorithms for nearly three years, and I'm pleased to announce that I've finally succeeded. While I can't promise the results are identical to Mitsubishi's own code, It is now possible to generate high-quality prints with these printers using entirely Free Software.
The library is called 'libMitsuD70ImageReProcess', released to the public under a GPLv3+ license.
Just to be absolutely clear, Mitsibushi is not responsible for this library in any way, and will not support you if you complain that the output is somehow deficient or your printer catches fire when you try to print pictures of Margaret Thatcher posing in her skivvies.
Here's the list of the now-functional printers:
- Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S, CP-D80DW
- Kodak 305
- Fujifilm ASK-300
While all of these models are expected to work, only the Kodak 305 has actually been tested. Please drop me an email or comment here if you have one of these printers and would like to help test things out.
In particular, if there's someone out there with a dual-decker CP-D707DW, there are opportunities for further enhancements that I'd like to try.
All code except for the library is now committed into Gutenprint, but is not yet part of any [pre-]release. So if you want to test this stuff out, you'll need to grab the latest Gutenprint code and libMitsu70ImageReProces out of git and compile/install them manually. Once this is a little more stable I'll package the library code in a tarball for simpler distribution.
In other news, while the Kodak 305's official Windows drivers only expose 4x6 and 8x6 prints, the printer firmware also supports the 6x6, 4x6-x2, and 2x6-x2 sizes that the Mitsubishi CP-K60DW-S supports. You'll need to ensure you're using the 1.04 firmware! I have also received reports that the '305 will accept the K60's print media, so in theory 5x7 and 6x9 support is possible.
Assuming that your distro already includes an up-to-date Gutenprint (5.2.12-pre4 or newer), here is what you will need to do in order to use these printers:
git clone http://git.shaftnet.org/cgit/selphy_print.git/ cd selphy_print make sudo make install cd lib70x make sudo make install sudo bash echo '/usr/local/lib' >> /etc/ld.so.conf.d/local.conf ldconfig exit cd ..
Once you have that done, run this with the printer attached:
sudo ./mitsu70x testjobs/mitsu_d70x_4x6-8bpp.raw # D70/D707/D80 sudo ./mitsu70x testjobs/mitsu_k60_4x6-8bpp.raw # K60 sudo ./mitsu70x testjobs/kodak_305_4x6-8bpp.raw # Kodak 305
As well as spitting out a page, you should see the following message in the output. Any WARNINGs or ERRORs are a sign that the library wasn't installed properly:
INFO: Image processing library successfully loaded
At this point, you can set the printer up using CUPS or your distro's printer tool, and all will be well.
(Note that Gutenprint 5.2.12-pre5 or newer will include all necessary selphy_print changes, but not the processing library)
As mentioned earlier, the Kodak 305 is a rebadged variant of the popular Mitsubishi CP-K60DW-S. Both models, along with their siblings (ie the CP-D70/D707/D80 and the Fuji ASK300), utilize a print engine that requires the host system to perform thermal compensation and other processing typically handled within the printer itself.
Not knowing how those algorithms work, these printers haven't been terribly useful under Linux, with the only prospect being a painful reverse-engineering of the Windows drivers.
A couple of months ago, Mitsubishi released a x86 binary-only CUPS driver for the D70 and D707 models. Other models weren't supported, and naturally this wouldn't work on other CPU architechures. Still, it provided a much more attractive reverse-engineering target, and as my interest came and went, I made slow progress.
Another wrinkle is that the CP-K60DW-S and Kodak 305 are slightly different from the others, to the point where my backend code was unable to print at all -- the printer communicates fine until the image data is sent over, and then nothing. All attempts to diagnose this further hit a dead end. That said, due to the unknown image processing algorithms, it was largely an academic exercise anyway.
Fast forward to a week ago. I lowballed a bid for a used Kodak 305 along with some unused media, in an "as-is, no warranty or returns" state. The printer arrived two days ago, and I got lucky; not only did the printer work, but it had about 140 prints worth of remaining media, far more than enough to get things going. An added bonus is that the printer had only logged 587 prints in total, a pittance for this kind of printer.
I quickly found and fixed a small pile of bugs, but successful printing still eluded me. I could find no differences in the data being sent between Windows vs Linux. Lacking a true hardware USB sniffer, I turned my attention to the enumeration to see if anything different was going on there.. and in the process I discovered something unexpected.
It turns out that these two printers enumerated differently under Linux than under Windows. Under Windows, only two endpoints were reported, one each for bulk input and output. However, under Linux, there were three endpoints; two for output and one for input. It seems that the backend was attaching to the second output endpoint, which accepted all commands, but not the actual image data needed to submit prints.
I'm at a loss to explain why the device would enumerate differently under Windows vs Linux; perhaps there's somthing funky going on behind the scenes and usbpcap only saw "cooked" data based on the driver's needs, whereas Linux's view more accurately represented the actual negotiation?
In any case, the backend now binds to the first pair of endpoints it finds, and can now print on all models of the printer family -- but the output is still unusably awful.
That success enables me to resume my reverse-engineering efforts, with an actual printer to test my experiments upon. Fortunately, the printers all use the same algorithms, differing only in a couple of tabular (CSV-based) data files. Inferring the internal data structures based on how the data flows into the system will be my next step.
Things are looking up, and perhaps sooner rather than later Mitsubishi's current printer family will be fully usable with Free Software. It's a shame this effort is even necessary, but I do love a challenge!