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
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!