Gutenprint / CUPS Dye-sublimation drivers

User report.  Claims it works on older fw, but unable to report the precise version that works vs doesn't.  Supposedly using recent-ish selphy_print, unknown version.

Need to update P520L printer to this FW and see what happens.

Does not happen on the official Mac drivers, but Gutenprint + lib70x shows it.

Best guess is that we have an inverted sign or off-by-one error in a compensation function that's causing the yellow channel to not get scaled correctly.

Printer reports idle when it's not.

Also printer sometimes hangs when submitting jobs.

Vendor driver has delays sprinkled around, investigate what may be necessary.

Right now we just shift the color data over by 2bits.  It looks like that's naive; it looks like we need some sort of gamma-aware 8->6 mapping on a per-channel basis.  This may require Gutenprint to spit out RGB data, and we perform the YMC conversion at the same time we apply gamma?  (not unlike the Mitsu D70 family..)

The printer's "gamma curve" settings don't seem to have any major effect.

It's also possible that my printer's head is just plain shot (there's already a bad row of pixels..), and that everything is actually fine.

We get failures when sending the printjob to the printer, with libusb reporting USB timeouts at random places.  There seems to be no consistency to when a transfer fails.  Using a hub makes this worse.

I have an additional two reports of a RPi3 failing USB transfers to a D80 when there is no ethernet cable plugged into the interface!

The K60/EK305 appears to work okay.

It's most obvious when printing something with a deep black; you'll see it bleed past a bit.

It's worse in Fine, better in SuperFine/UltraFine.

The problem is that two commands of different length use the same 2-byte prefix.  To distinguish between them we'll need to read the third byte, but only in that case as there are some commands that are only 2 bytes.

Or re-architect the command parser to handle this without extra hacks.

User repors that back-to-back prints cause the printer to hang.  This is with the stock USB backend that relies on standard flow control.

Fixing this will first require printing stuff back-to-back under Windows and sniffing it to see if there's any flow control in use.  Bleh

It would be *really* nice if we could figure out a way to ditch the component Y'CbCr output and use native YMC, but it's likely that only Canon ultimately knows if that's possible, and how.

There's something funky with the backend.

it prints the first page successfully, then keels over.

This suggests we need to apply a correction curve to the raw 16-bit data sent to the printer.

Uncertain if user was using the ICC profile.

Unfortunately it'll probably take some careful analysis of printing calibration targets to come up with an appropriate correction factor.

Not sure why. Perhaps a USB sniff under Windows would be helpful.

The first request succeeds, but subsequent requests hang when trying to talk to the printer.

I suspect what's going on here is that the response buffers we're posting are simply too small and the printer loses its mind.

Arguably is useful for the W5000 too, but that's more complicated.

The CP-M1E can rewind (gloss prints only), the CP-M1A cannot (I think!)

So add combining to make this work better.

One of the printers I have has a blank serial number string.  DNP's service tool has a way to update it, so ... figure out how that works, and implement it.

(I can't use the service tool to fix this as it's tied to a different model from the one with the bogus serial number)