mitsu70x: Documetation and bump the max job size.

backend_mitsu70x.c

@@ -98,8 +98,8 @@ static void mitsu70x_teardown(void *vctx) {
 	free(ctx);
 }
 
-// XXX is this enough?
-#define MAX_PRINTJOB_LEN (1024*1024*32)
+/* Max job size is 6x9+lamination, equalling ~38MB */
+#define MAX_PRINTJOB_LEN (1024*1024*40)
 
 static int mitsu70x_read_parse(void *vctx, int data_fd) {
 	struct mitsu70x_ctx *ctx = vctx;
@@ -340,7 +340,7 @@ static int mitsu70x_cmdline_arg(void *vctx, int run, char *arg1, char *arg2)
 /* Exported */
 struct dyesub_backend mitsu70x_backend = {
 	.name = "Mitsubishi CP-D70/D707",
-	.version = "0.02",
+	.version = "0.03",
 	.uri_prefix = "mitsu70x",
 	.cmdline_usage = mitsu70x_cmdline,
 	.cmdline_arg = mitsu70x_cmdline_arg,
@@ -354,3 +354,93 @@ struct dyesub_backend mitsu70x_backend = {
 	{ 0, 0, 0, ""}
 	}
 };
+
+/* Mitsubish CP-D70x data format 
+
+   Spool file consists of two headers followed by three image planes
+   and an optional lamination data plane.  All blocks are rounded up to
+   a 512-byte boundary.
+
+   All multi-byte numbers are big endian, ie MSB first.
+
+   Header 1:  (Init)
+
+   1b 45 57 55 00 00 00 00  00 00 00 00 00 00 00 00
+   (padded by NULLs to a 512-byte boundary)
+
+   Header 2:  (Header)
+
+   1b 5a 54 01 00 00 00 00  00 00 00 00 00 00 00 00
+   XX XX YY YY QQ QQ ZZ ZZ  SS 00 00 00 00 00 00 00
+   UU 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00
+   (padded by NULLs to a 512-byte boundary)
+
+   XX XX == columns
+   YY YY == rows
+   QQ QQ == lamination columns (equal to XX XX)
+   ZZ ZZ == lamination rows (YY YY + 12)
+   SS    == SuperFine mode (00 == off, 03 == on
+            Lamination always turns this on!
+   UU    == 00 == Auto, 01 == Lower Deck, 02 == Upper Deck
+   
+   Data planes:
+   16-bit data, rounded up to 512-byte block (XX * YY * 2 bytes)
+   
+   Lamination plane: (only present if QQ + ZZ are nonzero)
+   16-byte data, rounded up to 512-byte block (QQ * ZZ * 2 bytes)
+
+   Lamination appears to be these bytes, repeated:  28 6a  ab 58  6c 22
+
+   ********************************************************************
+
+   Command format:
+
+   -> 1b 56 32 30
+   <- [256 byte payload] 
+
+   e4 56 32 30 00 00 00 00 00 00 00 00 00 00 00 00   .V20............
+   00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00   ................
+   44 80 00 00 5f 00 00 3d 43 00 50 00 44 00 37 00   D..._..=C.P.D.7.
+   30 00 44 00 30 00 30 00 31 00 31 00 31 00 37 00   0.D.0.0.1.1.1.7.
+   33 31 36 54 31 33 21 a3 33 31 35 42 31 32 f5 e5   316T13!.315B12..
+   33 31 39 42 31 31 a3 fb 33 31 38 45 31 32 50 0d   319B11..318E12P.
+   33 31 37 41 32 32 a3 82 44 55 4d 4d 59 40 00 00   317A22..DUMMY@..
+   44 55 4d 4d 59 40 00 00 00 00 00 00 00 00 00 00   DUMMY@..........
+
+   LOWER DECK
+
+   00 00 00 00 00 00 02 04  3f 00 00 04 96 00 00 00   ........?.......
+   ff 0f 01 00 00 c8 NN NN  00 00 00 00 05 28 75 80   .......R.....(u.
+   80 00 80 00 80 00 80 00  80 00 80 00 80 00 80 00   ................
+   80 00 80 00 80 00 80 00  80 00 80 00 80 00 80 00   ................
+   
+   UPPER DECK
+   
+   00 00 00 00 00 00 01 ee  3d 00 00 06 39 00 00 00   ........=...9...
+   ff 02 00 00 01 90 NN NN  00 00 00 00 06 67 78 00   .............gx.
+   80 00 80 00 80 00 80 00  80 00 80 00 80 00 80 00   ................
+   80 00 80 00 80 00 80 00  80 00 80 00 80 00 80 00   ................
+
+   NN NN == Number of prints remaining on that deck.  
+   (None of the other fields are decoded yet)
+
+   -> 1b 56 31 30  00 00
+   <- [26 byte payload]
+
+   e4 56 31 30  00 00 00 XX  YY ZZ 00 00 00 00 00 00
+   00 00 00 00  00 00 00 00  00 00
+   
+   XX/YY/ZZ are unkown.  Observed values:
+
+   40 80 a0
+   00 00 00
+   80 80 a0
+
+   ** ** ** ** ** **
+
+   The windows drivers seem to send the id and status queries before 
+   and in between each of the chunks sent to the printer.  There doesn't
+   appear to be any particular intelligence in the protocol, but it didn't
+   work when the raw dump was submitted as-is.
+
+ */