Back in March, my reverse-engineered processing library for the
Mitsubishi CP-D70DW family of printers reached quality pairity with the
official Windows/OSX drivers and their SDK. This was a huge milestone;
it's now possible to drive these printers using entirely Free Software,
with no quality compromises, on non-x86 CPU architectures. To do this,
you will need Gutenprint
or newer, along with an up-to-date lib70x snapshot.
Here are the happy models:
- Mitsubishi CP-D70DW
- Mitsubishi CP-D707DW
- Mitsubishi CP-D80DW
- Mitsubishi CP-K60DW-S
- Kodak 305
- Fujifilm ASK-300 [completely untested]
I held off on announcing this achivement due to one rather annoying
problem. It seems most folks interested in using this family of
printers wanted to do so using the popular Raspberry Pi systems.
Unfortunately, for (at the time) unknown reasons, the CP-D70DW
spectacularly failed to print with RPi systems, with the image data
failing to transfer to the printer.
To further complicate things, I was unable to recreate the problem on
the Kodak 305 (aka a rebadged CP-K60DW-S) and an RPi2. Software-based
sniffs were useless, and things stayed at this impasse for quite some
What finally broke the logjam was one particularly motivated user
running into a similar problem with an RPi3 and a CP-D80DW model -- but
only when there was nothing plugged into the ethernet controller. This
was a bizarre development, and a working theory that there was something
funky going on with the RPi's onboard SMSC USB hub/ethernet chip began
He convinced Mitsubishi/Europe that it was in their interests to help
figure this problem out, and I soon found myself with a CP-D80DW and
several boxes of media on my doorstep and a backchannel to their
Try as I might, I was unable to recreate the problem on a RPi1 or RPi2,
but on an RPi3, I was finally able to trigger the failure. Armed with a
true USB sniffer and a copy of the USB spec, I was able to rapidly
identify what was acutally going on.
The USB2 spec (section 8.5.1) dictates that, when in high-speed mode, a
flow control mechanism (NYET/PING/[N]ACK) be used to maximize transfer
throughput. NYET is sent by the device after a successful transfer to
signal that it can't accept more. The controller then starts polling
the device with PING requests, with the printer responding with a NACK
until it's ready, at which point it responds with an ACK.
The problem, in a nutshell, is that the RPi's USB controller ends up
sending the PING requests so rapidly -- about 400 nanoseconds apart)
that it effectively triggers a denial-of-service (DoS) situation in the
printer. The funny thing is that the RPi's controller starts with a
PING interval of about 1.2 microseconds, and everything is fine until it
pulls in the timing, triggering the DoS.
(A regular PC with an xHCI controller demonstrates variable PING timing;
it starts at about 400ns, but backs off to about a 4us interval)
If other USB traffic is present, then the bus is too busy to send the
PINGs so rapidly, and the printer is fine. Notably, simply establishing
a physical link with the onboard (USB-attached) ethernet controller (even
if the interface is "down") generates sufficient traffic to mitigate the
problem. Plugging in a thumbdrive and dumping data back or forth is
also more than adequate.
I've reported this problem to both Mitsubishi and the RPi kernel folks.
I don't think one can expect much progress on the root cause of this
problem, but the above workarounds are at least adequate to using
these printers with RPi systems.
...Enjoy, folks, and happy printing.