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!

Located a few miles south from the tick farm, Royal Springs is a great place to cool off on a hot summer day. Here's the spring mouth, looking towards the Suwannee River.

It lived a good life, and went out doing what it loved..

Easily one of my favorite shots of the weekend.

Because "Normal People" are really boring.

Way to stay classy, Melbourne.

After spending the morning working up a sweat, what better way to cool down than to pop across the street and catch a rope swing into the Suwannee River?

This trail is through a property owned by the local water management district, and it is literally across the street from my land. During a normal flood season, there are parts of this trail that are under more than ten feet of water. During the 500-year flood that hit a few years ago, some of these trees were entirely underwater.

...what can I say, it's heaven.