Gutenprint / CUPS Dye-sublimation drivers

  • Status Closed
  • Percent Complete
  • Task Type TODO
  • Category Mitsubishi CP-Dxx family
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Medium
  • Reported Version 1.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Gutenprint / CUPS Dye-sublimation drivers
Opened by Solomon Peachy - 2019-06-26
Last edited by Solomon Peachy - 2020-03-27

FS#617 - Investigate Mitsubishi CP-M1E/M1A

just announced. 12s/print, 300dpi, "new engine", and 800 prints/roll.

Interestingly, they provide an ARM driver targeting Raspberry Pi systems.

Appears to still use host-based processing.

Closed by  Solomon Peachy
2020-03-27 04:57
Reason for closing:  Implemented
Additional comments about closing:  Further work will require direct access. I'm considering this done until then.
Solomon Peachy commented on 2019-06-26 13:25

Host processing uses a new set of tables:

  • 2x gamma curves (8->16bpp)
  • 3D LUT (same as other models)
  • Matte data file
  • Unknown parameter table, differing only in "HDENHGAIN" value.

So it appears that some new RE work is probably warranted..

Solomon Peachy commented on 2019-06-26 13:38
All ARM executables are _not_ stripped. WTF, but I'm not complaining! Printer uses different command language as D70 family. So it looks like a new backend is probably warranted. And a new library too, probably! Other details. Print engine is 14bpp. Matte data is 8bpp.
Solomon Peachy commented on 2019-08-18 13:50
Printer appears to use a comms protocol quite similar to the CP-D90, and the processing library is _very_ different to what came before. So this is going to require a significant reverse engineering effort, and I don't have the bandwidth to undertake this.
Solomon Peachy commented on 2020-02-17 02:11
D90 backend code now incorporates all known differences. USB PID unknown still, but when that's added the printer should be able to perform basic communication, and make it through a significant chunk of the imaging pipeline. 3D LUT and gamma/etc tables are loaded, matte data is loaded, and placeholders for everything else. Known headers are filled out properly. Windows spool format remains unknown. Gutenprint can't generate a spool file either. Figure that can wait until I get some sniffs.
Solomon Peachy commented on 2020-02-27 00:59
Lot of backend work. Decoded most of the Windows spool format, which has output differences from the RPi Linux driver! Backend should now be able to print a raw spool image, and most of the code needed to do all the processing except for sharpening. Completely untested!
Solomon Peachy commented on 2020-02-29 22:17
Tester popped up. Worked out the bugs printing raw windows spool files and status/etc queries. Implemented gutenprint job generation, fixed up the (many) bugs it uncovered in the backend, which is feature complete except for sharpening, which can wait. We're close.
Solomon Peachy commented on 2020-03-02 11:22
Printer can now successfully print from Gutenprint! Current quality seems to be okay for non-ICC output. Backend not upstream yet. Feature complete except for sharpening, which remains WIP with a couple of significant questions remaining.
Solomon Peachy commented on 2020-03-03 04:33
Sharpening implemented, and no longer crashes or obviously trashes memory. Needs testing but we're otherwise done.
Solomon Peachy commented on 2020-03-03 23:10
few more bugfixes. figured out the gamma table selection. Moved all processing code into library. Huzzah.
Solomon Peachy commented on 2020-03-04 19:42
New driver (and FW?) is pending that boosts print speeds ton ~9.5s/page. Will incorporate into backend once its effects are understood.
Solomon Peachy commented on 2020-03-05 02:54
So far seen only the driver. It exposes the 'speed' setting. Gutenprint updated to reference it, yay. At this point I need to seriously consider merging the heavily updated backends...


Available keyboard shortcuts


Task Details

Task Editing