Older blog entries for Pizza (starting at number 152)

Canon SELPHY CP910 and CP820

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.

Syndicated 2014-05-07 12:47:56 from Solomon Peachy

Yet more Dyesub printer hacking

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:

  • Support for multi-page print jobs
  • Sony UP-DR200 support
  • Canon SELPHY CP790 support
  • Vastly improved error detection and recovery for all Canon SELPHY models.
  • Printjob pipelining support for the DNP DS40/DS80
  • Support for the Citizen CX/CX-W/CY printers

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.

Syndicated 2014-02-07 15:00:10 from Solomon Peachy

A little Photo Organizer love

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.

Syndicated 2014-02-07 14:07:59 from Solomon Peachy

DNP DS40 and DS80

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:

  • An intelligent CUPS backend that lets us pipeline print jobs in a status-aware manner, plus query printer information
  • Support 5x7 and 3.5x5" print sizes on the DS40
  • Matte lamination support
  • Better margin specifications
  • Support for the 300x600 "high-quality" print mode

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. :)

Syndicated 2013-12-19 03:14:18 from Solomon Peachy

Mitsubishi CP-K60DW-S

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?

Syndicated 2013-11-24 16:08:06 from Solomon Peachy

Kodak 605 works!

The Kodak 605 Photo Printer is their replacement for their earlier 68x0 series. And, true to form, it's incompatible with everything that came before.

Last night, I commited a backend for the Kodak 605 photo printer. Tonight, the last of the known bugs were fixed, and it appears to work!

Yay, that just leaves most of the Mitsubishi models (CP3020D/DA, CP-D70/707, CP-D9550/9600) that need testing/validating, plus whatever else comes along in the mean time.

Syndicated 2013-11-24 03:17:18 from Solomon Peachy

12 Sep 2013 (updated 24 Nov 2013 at 04:11 UTC) »

Okay, Freescale, I give up.

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.

...It's not much of a race.

Syndicated 2013-09-12 02:56:27 (Updated 2013-11-24 04:11:59) from Solomon Peachy

cw1200_spi now works properly, and is in backports!

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. :)

Syndicated 2013-08-28 02:27:21 from Solomon Peachy

I made it onto LWN.net's top kernel contributor page!

This week's (Linux Weekly News)[lwn.net) (kernel)[http://lwn.net/Articles/563977] page has information on the upcoming Linux 3.11 release. (Note that this page will be opened up for non-subscribers next week. Subscribe to LWN. They are awesome. Just do it. I'll wait)

I came in at #7 on the top contributor list, with 15,510 lines of code added/changed thanks to the ST-E CW1200 driver getting mainlined. This represents a whopping 1.6% of the overall churn for this kernel release.

While I wasn't the original author of the cw1200 driver (credit for that goes to Dmitry Tarnyagin), over the past couple of years I've rewritten large chunks of its core and substantially tweaked the majority of what's left -- and this mainling effort has taken the better part of a year to accomplish.

But I digress. Getting onto that "top contributors" list was one of those personal/professional milestones that I never expected to attain, especially now that $dayjob has taken me out of the WiFi/802.11 and Linux kernel hacking realms in favor of WPAN ICs with a healthy dose of microcontrollers on the side.

Syndicated 2013-08-22 14:20:42 from Solomon Peachy

linuxaldl hacking continues

My linuxaldl fork now supports bitfield and lookup table data types, though I'm still quite a ways off from testing anything. Further digging into the Pin-E (aka 160bps) signalling shows that it doesn't use RS232-compatible framing:

[160bps pin-E serial interfacing] (http://wbo2.com.au/~techedge.com.au//vehicle/aldl160/160serial.htm)

To make a long story short, a viable solution is to clock the serial port to 10x the actual bit rate, and treat each "byte" received as a single bit, which we'd then translate into 9-bit sequences to decode.

Unfortunately this is completely incompatible with how linuxaldl handles the pin-M (ie 8192baud) protocol, so it looks like I'll need to figure out the best way to do this and probably throw away a couple of prototypes. So it looks like the plug-it-in-and-see-what-happens test is further off than I'd hoped.

Anway, time for bed. Tomorrow I need to put this on hold so I can hunt down a BUG trigger with the cw1200 driver on some SPI hardware. That and I may have some $dayjob work to take home with me too.

Syndicated 2013-08-22 04:11:16 from Solomon Peachy

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