Recent blog entries for Pizza

Progress with the Mitsubishi CP-K60DW-S and Kodak 305

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!

Syndicated 2016-09-02 13:22:23 from I Dream of Rain (free_software)

Netflix and Hurricane Electric's IPv6 service

For a few years now, I've used Hurricane Electric to get a native IPv6 tunnel to the internet. I've also been using Netflix streaming since it was first introduced. Life was good.

Netflix, on behest of its content suppliers, has started to crack down on folks using VPNs or proxys, because they're often used to work around artificial geographical restrictions.

A day or two, that blocked proxy list grew to include Hurricane Electric's IPv6 service, which I make heavy use of. Despite a US billing address, being physically located in the US, and using a US tunnel endpoint, Netflix treats me as an eeeevil bad person.

Their only advice is "disable your proxy", which is not an option as I have IPv6-attached servers that need to remain online.

Netflix's applications don't provide a way to utilize IPv4 only, which basically means I had to figure out a way to force netflix traffic to travel over IPv4. Ideally, I'd block the IPv6 AAAA dns lookups, but there's no simple way to do that.

However, one can just null-route the entire Netflix IPv6 address range:

    ip -6 route add blackhole 2406:DA00:FF00::/48

This will, after a little delay, cause Netflix to fall back to using IPv4, and all is well.

Ironically, being able to avoid this sort of BS is one of the reasons why Netflix was such a compelling service, but the balance is tilting back towards piracy providing a better overall user experience. Part of me hopes that the stats show a nice correlation between making legal services less useful and piracy rates going back up.

Addendum: About a year ago, my ISP (Comcast Business) rolled out native IPv6 service which by all acconts works quite well. Unfortunately, they don't offer a static IPv6 allocation, which renders the whole thing useless for my needs.

Syndicated 2016-06-04 12:41:06 from I Dream of Rain (free_software)

This is why ECC RAM is a good thing

    [2954432.978093] [Hardware Error]: Corrected error, no action required.
    [2954432.982285] [Hardware Error]: CPU:6 (10:8:0) MC4_STATUS[-|CE|MiscV|-|AddrV|CECC]: 0x9c5cc820001c017b
    [2954432.986453] [Hardware Error]: MC4 Error Address: 0x000000054a089400
    [2954432.990528] [Hardware Error]: MC4 Error (node 1): L3 data cache ECC error.
    [2954432.994525] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: EV
    [2954432.998450] mce: [Hardware Error]: Machine check events logged

Who knows what was going at the time...

Syndicated 2016-02-24 02:08:18 from I Dream of Rain (free_software)

Sinfonia CHC-S6145 (CS2) and Ciaat Brava 21, working!

Over the past year, I've written a bit about the situation involving the Sinfonia CHC-S6145 printer and its rebadged sibling, the Ciaat Brava 21. To summarize, the printers worked but required use of a proprietary, binary-only library ('libS6145ImageProcess') to perform thermal compensation and other transformations to the image data in order to generate sane output.

To make a long story short, I set out to reverse-engineer how that library worked... and a couple of weeks ago, I succeeded, with my reimplemented library generating completely identical results.

After some back and forth with Sinfonia, I'm quite pleased to announce that my re-implmented library, called 'libS6145ImageReProcess', is now released to the public under a GPLv3+ license. Except for the differing name, it is a drop-in replacement for the Sinfonia library.

Just to be absolutely clear, Sinfonia 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 print images of Donald Trump biting the heads off of adorable kittens.

Now in order to actually utilize these printers, you'll need to compile and install three components:

  • Gutenprint 5.2.11 (just released!)
  • libS6145ImageReProcess library
  • Latest selphy_print backend code

I should have the necessary backend code in the Gutenprint development repo soon, but due to licensing complications the library will probably remain separately distributed.

Particular thnaks go to Sinfonia and Ciaat for providing documentation on the printer communication protocols, and Matt Koglin for his SinfoniaCam(tm) and many, many rounds of testing.

This has been a long time coming, and is the culmination of quite a bit of work. I hope it proves useful, and if you do purchase one of these printers intending to use it with Linux (or a more obscure OS), please let your Sinfonia distributor know. :)

Syndicated 2016-01-30 20:24:40 from I Dream of Rain (free_software)

Lifting the skirts of Kodak photo printers

You have to hand it to Kodak. They have been selling their workhorse 6850 dyesub photo printer for more than ten years, and are still actively supporting it with updated drivers and firmware. It's even outlasted one of its successors (the 605), which is no longer sold, yet is still actively supported.

One of those firmware updates led to a discovery that resulted in a flurry of hacking on the 6800/6850 and 605 backends, resulting in considerably improved reliability, robustness, and performance. As well as many bug fixes, both backends now support full job pipelining and vastly improved status and error handling.

So what had I learned? The Kodak 68x0 family are variations of the Shinko S1145 and the Kodak 605 is actually a Shinko S1545. Digging deeper into other Kodak models, I discovered that the 7000/7010/7015 are variations of the Shinko S1645, and that the 8810 is a Shinko S1845.

I'd done my earlier reverse-engineering work on these Kodak models before some kind folks at Shinko/Sinfonia sent me documentation on several of their printers -- So when I re-examined what I had previously figured out with the other docs as a reference, I discovered that from a protocol perspective the 68x0/S1145 models were 6" variations of the 8" S1245, the 605/S1545 and 70xx/S6145 models were very close to the S2145, and the 8810/1845 are apparently identical to the S6245.

This means that I should be able to support the 70xx and 8810 printers with only minor modifications to the existing backend code. Granted, until I can get my hands on any of these printers all of this is conjecture.

So, I'll re-iterate my call for testers for these printers:

  • Shinko CHC-S1245 (aka Sinfonia E1)
  • Shinko CHC-S6245 (aka Sinfonia CE1)
  • Kodak 8810
  • Kodak 7000/7010/7015
  • Kodak 605 (Need to ensure no regressions were introduced)

As my personal printing needs are very well met at this point and these are all fairly expensive models (especially the 8810 and 70xx series), I can't justify buying more printers just to try and make them work with Linux. Someone else is going to have to step up to help make this possible.

On that note, I should mention the S6145/CS2 (and the Ciaat Brava 21), where the situation is a bit more complex. The backend is already written and partially tested, but it currently relies on a proprietary library that is only available in binary form - and which I lack permission to redistribute.

I'm pursuing a multi-prong approach to rectify that situation. In order of desireability:

  • Obtain source code to the library
  • Obtain algorithmic documentation so I can independently re-implement the library
  • Obtain permissions to redistribute the (binary) library, and also get it compiled for a variety of ARM targets
  • Reverse-engineer the library so I can re-implement it

Let me just say that curiousity, in of itself, is poor motivation for enduring the the combination of tedium and frustration that comes from trying to reverse-engineer an opaque blob of x86 code.

Ugh. I need to get out more.

Syndicated 2015-09-01 21:40:31 from Solomon Peachy

Shinko S1245 and S6245 (AKA Sinfonia E1 and CE1)

A few months ago I received a semi-official documentation dump from Sinfonia. Thanks to that information, Gutenprint now claims full support for both the S1245 and S6245. These models required new backends, and last night I committed the last of the necessary changes.
Both printers should now work -- in theory, anyway.

As I don't own or have access to either printer, this code has received no testing whatsoever, and as such might result in kittens swallowing the earth with impeccable wide-eyed cuteness as they mew and cry out for belly rubs. Oh, the humanity!

If there's someone out there who wouldn't mind donating a printer to the cause, or at least be willing to go a few rounds of testing, drop me a line.

Do it for Free Software. Do it for World Peace. Do it for Kittens.

Syndicated 2015-07-03 19:41:38 from Solomon Peachy

Ongoing Dyesub Photo Printer Developments

Gutenprint 5.2.11-pre1 was released this weekend. It contains the usual support for a pile of new printers, and improvements for many previously-supported models. I'll only speak about stuff I had a hand in:

First, the newly-supported models that are reported to be working quite well:

  • Canon SELPHY CP820 and CP910
  • Citizen CW-01 / Olmec OP900
  • DNP DS620/DS620A
  • Mitsubishi CP-3800DW

Next, new models that were added but have received no testing:

  • Sony UP-CR10L (aka DNP SL10)
  • Shinko S1245 [1]

Models that have much-improved support:

  • DNP DS40/DS80/RX1 [4]
  • Citizen CX/CX-W/CY [4]
  • Canon SELPHY CP900
  • Kodak 605, 6800, and 6850 [3]
  • Mitsubishi CP9550 family (including the CP9550DW-S!)
  • Sony UP-DR200

Finally, models that are improved or added, but will require muh more work before they are considerd useful:

  • Mitsubishi CP-D70/D707/K60/D80 [2]
  • Ciaat Brava 21 [2]
  • Kodak 305 [2]
  • Kodak 8810
  • Shinko S6145 [2]
  • Shinko S6245

Some notes:

[1] The Shinko S1245 is notable in that I've already completed a full-featured backend that just needs testing with a real printer.

[2] These models are all related, and use an unknown color scaling/dithering algorithm that must be reverse-engineered before the printers become usable.

[3] The Kodak 68x0 family in particular is consirerably more robust in the face of errors, media mismatches, and status reporting.

[4] The DNP/Citizen backend was greatly improved, and is far, far more robust than it used to be. Error detection and recovery, general buffer management, handling media/printjob mismatches, and even general status queries were all improved.


Oh, just to forestall the question, all printers with multicut modes (eg 2x6 strips) have full support, but will require a minor patch to be applied to Gutenprint before compiling.

I'll end this with my usual request for testers, especially ones with access to the Shinko S1245, Sony UP-CR10L, and DNP SL10 models since the work is already completed. As for what's next, the Shinko S6245 is the most promising candidate.

Thanks go out to everyone who has helped -- be it testing or providing USB dumps; sending over documentation (Yay, Shinko!), or actual printers (Yay, LiveLink!). There are others I would like to acknowledge but they have asked to remain anonymous. Thank you, all.

Syndicated 2015-06-29 12:15:48 from Solomon Peachy

Progress on the Shinko S1245, S6145, and S6245

A few weeks ago, a kind gentleman at Sinfonia sent me a pile of documentation on their S1245, S6145, and S6245 printers.

The S6145 and S6245 use a similar command language to the S2145, but the S1245 is quite different. So I decided to start with the latter, and created a new backend for it. It's now complete, but needs testing.

Support for the S6245 will probably follow, likely added into the existing S2145 backend as most of their code will be shared.

Unfortunately, the S6145 is another matter. While its command language is quite similar to the S2145, it has some peculiar data format requirements.

While the spool data is packed 8-bit RGB, the printer driver (aka our backend) is expected to convert it to 16-bit planar YMC+L data. That is easy enough to accomplish, except the data also needs to be massaged via an unknown algorithm combined with an opaque data blob that the printer supplies.

If this sounds familiar, it's because that sounds eerily similar to what the Mitsubishi K60/D70/D707/D80 printers require, complete with a file providing the raw lamination data and pile of tabular data that feeds into the transformation algorithm. This is strong evidence that the S6145, the CIAAT Brava 21, Kodak 305, and those Mitsubishi models all use the same basic print engine.

The Sinfonia rep wasn't able to provide any further details on the algorithm, though he did provide a set of binary x86 and x86_64 libraries that perform the necessary transformations. So it's a sort of bad news, good news situation.

Anyway. At this point, the S1245 backend is ready for testing, and since I can't justify buying yet another high-end photo printer, that means I'll need a volunteer to test this stuff out.

In the mean time, I'll probably work on support for the S6245, which will also eventually need testing. Then I'll move on to the S6145, get the core backend in place, then teach myself some x86_64 assembly and get to reverse-engineering the necessary algoritms and maybe eventually get somewhere.

So, does anyone have a spare S1245, S6245, and/or S6145 printer to toss my way? It's for a good cause!

Syndicated 2015-02-18 04:17:51 from Solomon Peachy

The current state of the Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S, and CP-D80DW printers under Linux

The problem:

Over the last month or so, I've received on average two questions a week about these printers, mostly along the same lines of "I can't print with them, help!"

The short answer

They don't work with Linux, and this isn't likely to change anytime soon.

The longer answer

With the Mitsubishi CP-D70 and D707, If you use the Gutenprint 5.2.11-cvs code later than August 14, and the backend code from at least October 4, you will be able to successfully generate prints. The CP-K60 still won't print at all due to incomplete knowledge about printer backend protocol, and I have not seen what changes the CP-D80 incorporates.

Unfortunately, while the CP-D70 and D707 are able to successfully print, the output is all screwed up. The Windows drivers perform non-linear color scaling that requires gamma correction; this is annoying but would be straightforward to figure out, except the drivers are also doing some sort dithering.

How bad is this dithering? A test job with six nominal colors results in a printjob that contains over 18,000 (16-bit) color values. Even a simple "print a page with a single, pure color" job results in dozens (if not hundreds) of colors as the driver adjusts the intensity according to some unknown algorithm.

The pithy answer

Mitsubishi actually wrote Linux drivers for all of these (and other!) printers, but only provides them as part of their Kiosk solutions, not for normal end-users. So, don't reward manufacturers that snub Linux users, and support those who do.

The alternative answer

There are many competitive alternatives (both price-wise and performance-wise) which have solid support under Linux. In particular, here's what I'd recommend if you want a kiosk-class, workhorse photo printer:

  • DNP DS40, RX1, or DS80
  • Citizen CX, CX-W, or CY
  • Shinko S2145 / Sinfonia S2
  • Kodak 6800, 6850, or 605
  • Sony UP-DR150 or UP-DR200

Several other models from these manufacturers should (in theory) work okay, but the above represents a known-good list. Note the utter lack of any Mitsubishi models; as of this writing, none of their printers play well with Linux.

The pleading answer

In case anyone over at Mitsubishi is reading this, how about tossing me some documentation and a printer or three to play with? Proper Linux support will only help you sell more printers!

Syndicated 2014-11-22 13:35:03 from Solomon Peachy

30 Oct 2014 (updated 22 Nov 2014 at 14:13 UTC) »

Further printer work

Okay, so I guess I was wrong about additional printer hacking. Despite the 12-hour days at the office over the past few weeks (we got our first silicon back, and software is the ring that binds everything together in the darkness), I'm still spending time writing code when I get home.

First, I added support for the Sony UP-CR10L and its rebadged bretheren, the DNP SL10. I've had these on my to-do list for a while; I'd already decoded everything and updated the existing UP-DR150/200 backend to handle the new bits, but never got around to adding proper support into Gutenprint. That's now done, and once I get the USB PIDs, it should JustWork(tm).

Beyond that, I've knocked out a few things on the bug list. One I just fixed affected pipelined printingon the DNP/Citizen printers, and it was most easily triggered by multi-page print jobs. With Gutenprint 5.2.10's backend, the printer would just abort the job after the first page, but if you were using a development snapshot after 2014-06-04, it would automatically retry the job, resulting in an endless printing of page 1 over and over again.

The bug was due to the backend mistakenly treating the "Printing, with one available buffer for a 300dpi or small 600dpi job" status as an error.

...Oops.

At least folks won't have to wait for the next Gutenprint release to pick up the latest backend code.

I have a rather large photo backlog from the past month to sort through. That will be my weekend project..

Syndicated 2014-10-30 02:38:37 (Updated 2014-11-22 14:13:15) from Solomon Peachy

159 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!