The venerable Kodak 6800 and 6850 printers are true workhorses; it's not
uncommon to see them flogged on eBay with upwards of 200,000 prints on
them -- not because they are worn out, but because they tend to outlast
the systems they're plugged into.

I originally added support for these models to Gutenprint the better
part of two years ago, and through some helpful volunteers, I was able
to reverse-engineer enough of the printer communications to write an
open-source CUPS backend to enable them to print under Linux.

That seemed to be good enough, and I generally forgot about these
models.. until a few months ago, when the folks over at
LiveLink arranged to have an Kodak
6850 sent my way. (These guys are awesome, BTW!)

Having full access to one of these things made it far easier to poke and
prod and generally reverse-engineer the printer communications.
Consequently, I've mostly decoded the printer media status (now with
print counts!) and media query messages, and greatly improved error
detection and recovery.

It's probably safe to say it now works better under Linux than it ever
did with the Official Windows/OSX drivers, though without access to a
5x7 conversion kit and media I'm sure there's something I've missed.

In other news, I'm still hunting down some bugs involving the Sony
UP-DR200, Canon CP900, and Mitsubishi CP-D70/CP-K60 models, but with
only indirect access progress is slow.

It would be so much easier if the manufacturers of these things could
toss some documentation my way. It could only help them sell more
printers and media, after all..

It seems my early enthusiasm was a little misplaced, as "some degree of
driver-side color management/mapping" became considerably more involved
than I'd first expected.

It turns out that rather than the subtractive Cyan/Magenta/Yellow
primary data sent to the earlier CP-series printers, or even the
additive Red/Green/Blue primary data used by many others, The CP820 and
CP910 expect their data in a perceptual, Luminance-based format, not
unlike what one finds in television and video formats.

My best guess is that the printers use the JPEG YCbCr444 format and
coefficients (as opposed to the ITU-R BT.601, BT.709, or BT.2020, or
various YUV colorspaces). Conversion between these colorspaces is
fairly straightforward. Here's the code for the JPEG transformations:

Unfortunately, due to Gutenprint's internals and the fact that the
printer expects the YCbCr data in a plane-interleaved format, this will
be a little more invasive to implement. Consequently, it will likely
not land in Gutenprint until after the 5.2.10 release.

In other photo printer news:

Multi-cut support for selected printers is in the works

Support for the Sony UP-CR10L (and DNP DS-SL10) is in the works

Improved Kodak 6800/6850 status reporting

I'm awaiting sniffs from Mitsubishi CP-K60DW-S and CP-D9550DW-S printers, which should lead to improved support

The Mitsubishi CP-D70W is confirmed to work, but apparently needs major color curve tweaking

As always, the best way to improve a printer's support is to send one my
way, preferably accompanied by programmer documentation. :)

For more than a decade, Canon's SELPHY printers have been largely
evolutionary. While their bolt-on features have steadily improved
(in-printer touchup, better screens, UIs, etc) the core printer engine
itself has remained nearly unchanged from the outset. This is most
visible when you consider they've used the same media packs the whole
time.

The outlier here was the SELPHY ES series; they used different,
all-in-one media packs to improve printer handling, but putting aside
the physical differences, under the hood it was the same basic print
engine, supporting the same print dimensions. Also unique to the ES
series were a few minor variations in the printer spool data format, but
with the exception of the CP790, the CP series has remained completely
compatible for the entire life of the family.

Until the CP820 and CP910, that is. These two use an entirely new print
data format (different headers, and RGB instead of CMY data) and despite
using the same CP-series media, also sport a slightly different print
engine that runs at a slightly higher resolution than the older models.

Another major change is that the CP820 and CP910 break from tradition
and no longer need a special driver/backend to interactively send data
over; now the whole thing is just dumped over in one big blob. This was
an unexpected (and welcome!) change.

Unfortunately it looks like the printers still need some degree of
driver-side color management/mapping; figuring that out is going to be
tricky. Still, with luck, these printers will be supported in
Gutenprint 5.2.10.

Over the past month, there's been a push to get the Gutenprint codebase
in shape for the long-overdue 5.2.10 release. This will be the first
release incorporating the various CUPS backends I've written plus an
expanded supported printer list.

This has resulted in a flury of bugfixes and improvements to the
backends, including:

The Citizen printer support deserves its own set of comments. It turns
out that the DNP DS40/DS80/DSRX1 models are just rebadged Citizen
CX/CX-W/CY models (down to the same USB IDs!) and they all use an
indentical command language.

There are more Citizen models (CW-01, CW-02, OP900, OP900II) that have
been rebadged by others too, and every single one of these supposedly
supports the same command language as the CX/CX-W family. Most notably,
Mitsubishi's CP3800 appears to be a rebadged CX-W.

I like it when things JustWork(tm)! Unfortunately, since I don't know
the USB IDs for that second list of printers, I can't add them to the
backend match list.

My interest in adding more printers to Gutenprint for the sake of it has
waned somewhat, for several reasons -- First, my personal and
professional printing needs are now well-met. Second, I have less free
time to devote to such things. And finally, the norm for these
dye-sublimation photo printers seems to be to require an intelligent
backend, and I can't begin to write one without access to the particular
printer.

The Mitsubishi CP3800, CP9550, and CP3020 series haven't been tested.
The CP-D70/D707/K60 models are known to need a backend (and it's
written!) but my original tester disappeared. (I've also started
reverse-engineering the CP9600 spool file format, but that's on hold
until after tax season..)

The Kodak 9810 and 8500 (itself a rebadged CP3020) also remain untested.

So, if anyone out there has access to one of these printers and is
interested in helping improve their Linux support, speak up!

Similarly, if there's some other dye-sublimation photo printer you'd
like to see working under Linux, we can probably help each other out.
The recent Citizen/DNP and Shinko/Sinfonia additions/suppport were the
result of such collaborations.

The software that powers my photo archive (aptly named Photo Organizer)
hasn't seen much attention in the past few years or so. That's mostly
because it does what I need with little fuss, and the other users either
don't exist any more or are satisfied with what it is.

The other reason it hasn't seen much attention is that there's so
much tecnhical debt in that codebase that all of the substantial
feaures I have on my eventual to-do list require some major plumbing
work.

So, the result is that in the past three or so years, development's
slowed to a trickle of bugfixes. The notable exceptions are addition of
a few more esoteric image formats, and updating the default themes to
take advantage of now-common CSS3 constructs. Not exactly
earth-shattering!

Last night, I finally sat down and added a major new feature, a
(read-only) JSON-RPC interface that exposes the same sorts of
information as the RSS feed generator.

My primary goal is to enable gnome-photos to directly interface with
Photo Organizer, but this JSON-RPC interface will enable many more
things. Unfortunately the data exported through the RPC API is far from
complete, but I only see that improving as I figure out what to do with
this thing.

I've spent several evenings over the past week improving Gutenprint's
support for the DNP DS40 and DS80 dye-sublimation printers. Aside from
their respective 6" and 8" print widths, they are otherwise identical
feature-wise. Here's what's been added so far:

Next up will be to add sane multi-cut print modes (for example,
obtaining 3* 8x4" prints cut from a single 8x12 sheet). This is
considerably more challenging as Gutenprint doesn't really support this
sort of thing.

I should ask around at the office if anyone wants some prints made; if
I'm going to generate a pile of test prints I might as well generate
ones worth keeping. :)

Recently Mitsubishi announced their CP-K60DW-S photo printer. Outwardly
it is identical to their existing CP-D70DW, except for the use of red
labels instead of grey. Beyond that, it appears to be functionally
equivalent (even uses the same media) to the CP-D70 series, although not
as fast.

This morning I dug into the spool file format the CP-K60DW uses. It's
almost identical, though different enough to be annoying. Most of the
changes had to do with print sizes; they're all slightly different, and
there's support for 6x6 prints (but not the 6x9 the CP-D70x supports)

Some judicious decoding later, and Gutenprint now theoretically supports
the CP-K60DW-S. Of course, lacking access to one of these printers I
have no way of testing this, and can only hope its command stream is
identical.

In the process I discovered and fixed a couple of bugs relating to
command padding on the the CP-D70 series. Anyone out there with access
to any of these printers (Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S)
that's willing to help me out?

The Freescale "Freedom" FRDM-KL25Z boards have a lot going for them.
They're cheap ($13), and sport an ARM Cortex M0+ core in an Arduino-ish
form factor, with a fancy "OpenSDA" USB-based flash/debug thingey bolted
onto the side for user-friendlieness.

Unfortunately.. they botched the execution in many ways; some subtle,
some less so.

Let's start with the first impression. In order to get anything more
useful than marketing materials from Freescale's web site, you have to
register. They then hand this info off to a distributor who proceeds to
email and call you before you have a chance to meaningfully evaluate
anything.

The actual datasheets and programmer manuals were okay; not the worst
I've seen by any means, but not all that great either.

But the software side of things is another story. The only thing they
offer is a ginormous plugin for an obsolete version of Eclipse that
supports all of their microcontrollers... via a code generator.
Theoretically, once you generate that skeleton codebase it's usable
outside of Eclipse.

At least you can extract the not-quite-CMSIS-compliant processor headers
from that morass. But those files say "all rights reserved" which makes
them technically unredistributable. Sigh.

But the best part, the part I spent the last day and a half fighting,
was their "OpenSDA" programming/debugging mechanism.

In theory, it's a smart design -- It presents as a composite USB device
consisting of a serial port and a virtual mass storage device. The
serial port gives you the console, and to program the controller's
flash, you just copy a new firmware image over to the filesystem.

It turns out there's nothing open about it.

OpenSDA is about as proprietary as it gets. To actually use it as a
debugger under Linux you'll need a proprietary 32-bit-only binary
drivers+libraries. That's right, they don't even supply an application
to use it -- even a GDB server will cost you extra.

So it's useless as a debugger. What about as a flasher/programmer? It
fails even more spectacularly there, thanks to it simply not working
under Linux (or even OSX), due to gross violations of the USB mass
storage spec.

In all fairness, they did eventually fix these problems (both in their
bootloader and their flasher "application").. but you'll still need a
native Windows system (not a VM, because their USB enumeration is just
that badly broken) to do the update. Once you have the new application
running, it works well enough, though it doesn't complain if you try to
write something too large.

The one saving grace is that Keil released a firmware file that replaces
the anything-but-OpenSDA "flasher+debugger" with ARM CMSIS-DAP compliant
interface that JustWorks(tm). Unfortunately, it's only usable as a
debugger with the tools I have, so to actually flash an image, you have
switch back to the OpenSDA "applications" -- which, since they pulled
their fixed-for-Linux bootloader, requires a Windows box.

All I want to do is write a "Hello World" program on this thing, and
I've wasted the better part of two days on things that should
JustWork(tm).

So much to "Open" or "Freedom" -- Grand ideals ruined by horrible
execution. Unfortunately, this is the sort of thing I've come to expect
out of Freescale. Every encounter leaves me wanting to bash my head
againt the wall.

A month or so ago
I compared Freescale to someone shooting themselves in both left feet.
Maybe I should add "while running backwards" to that analogy.

In comparison, STMicro's STM32F4DISCOVERY board ($15 with a Cortex-M4!)
isn't without its flaws, but it took less than half an hour to assemble
everything I needed to flash and debug the board, and their
documentation and software samples are comprehensive and excellent.

I just submitted two patches to the cw1200_spi driver; hopefully they'll
make it into 3.11-final, but if not, they'll go into 3.11.1 instead.

A user (Dave Sizebur) was trying to get this driver working on a
Beagleboard xM, only to discover near-immediate BUG() triggers when the
driver was loaded. This was due to the the driver attempting to perform
a SPI transfer in interrupt context -- ironically, trying to disable the
interrupt in the hardware.

Apparently some (most?) SPI controllers use asynchronous calls -- which
can sleep, which is a no-no in interrupt context. The hardware I used
to develop this driver (an ancient Sagrad Kraken board based on a
Samsung s3c2440) used synchronous, non-sleeping calls.

The solution was to disable the interrupt via the linux disable_irq()
call instead of masking it on the hardware itself.

The second problem was a hang (not a deadlock) caused by improper
locking in the SPI driver's attempt to emulate the semantics of the SDIO
layer's claim/release_hardware API. When there was lock contention,
nothing actually tried to wake up the lock requestor when the lock was
eventually freed. This bug never presented itself on my hardware, more
out of dumb luck than anything else.

Several days and a dozen or so e-mail exchanges later, Dave had a
working cw1200_spi driver. His patience in this endeavour was
apprecited, especially since I didn't have any SPI-capable hardware
handy.

The known bug list is back down to zero, just where I like it. But it's
the unknown ones that get ya.

Meanwhile, the small pile of patches I've submitted to the linux
backports project have been merged,
so the next backports release will include support for the cw1200 driver
going back to the 2.6.34 (SPI) and 2.6.32 (SDIO) kernels. With a little
more effort, support should be possible going back several more
releases, providing there's sufficient interest.

Since there are still some out-of-tree patches (unmerged fixes and
regulatory-approval-type stuff) for the cw1200 driver, I'm considering
releasing my own set of backports tarballs if there is sufficient
interest.

"Sufficient interest" basically means it's not going to happen unless
someone asks, because I have other projects to keep me busy. :)