From 742501be675c95b6ddfac5b73ee9685587a35964 Mon Sep 17 00:00:00 2001 From: Arti Zirk Date: Sun, 1 Nov 2026 23:38:53 +0200 Subject: [PATCH] docs(xie): the compression schemes the XIE headers define DEC XIE 2.3 (what the VT1200 speaks) defines exactly five, in XieAppl.h: XieK_PCM 0, XieK_G31D 1, XieK_G32D 2, XieK_G42D 3, XieK_DCT 4. XieK_DCT is the JPEG/DCT scheme; there is no XieK_JPEG and no TIFF/RLE/LZW constant. Worth recording because it explains the BadValue/BadMatch history: the server's ProcSetTransport allows PCM unconditionally, allows G3/G4 only for a bitonal image outside XieK_Tile mode, and allows DCT only for a NON-bitonal image outside XieK_Tile and outside XieK_BitByPlane -- anything else is BadValue. A bitonal 64x64 photomap in Tile mode therefore admits PCM only, which is what the working client sends. In ProcGetStream/ProcSetStream G31D and G32D are literally "not yet supported", and DCT/G42D are delegated to the DDX hooks DdxEncodeDct_ / DdxEncodeG4_ -- i.e. to the board's accelerator. The X Consortium X11R6.1 lineage (xc/) is a different, larger list: ten Decode/EncodeTechnique values including JPEGBaseline 10, JPEGLossless 12, TIFF2 14 and TIFFPackBits 16. Cross-referenced with DTJ Vol. 3 No. 4 (Fall 1991), "Hardware Accelerators for Bitonal Image Processing": the ASIC described there is a CCITT (G3-1D, G3-2D, G4-2D) decompressor plus scaler and rotator -- the scalution hardware -- while JPEG/DCT is that article's continuous-tone counterpart (citing C-Cube CL550-10, not the bitonal chip). The two map onto XieK_G42D and XieK_DCT. --- xie/XIE_COMPRESSION_SCHEMES.md | 138 +++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 xie/XIE_COMPRESSION_SCHEMES.md diff --git a/xie/XIE_COMPRESSION_SCHEMES.md b/xie/XIE_COMPRESSION_SCHEMES.md new file mode 100644 index 0000000..8846501 --- /dev/null +++ b/xie/XIE_COMPRESSION_SCHEMES.md @@ -0,0 +1,138 @@ +# Compression schemes in the XIE headers + +Two different XIE lineages are vendored here, and they do **not** define the same +set. The terminal speaks the first one. + +## DEC XIE 2.3 — what the VT1200's server implements + +`docs/dec/xie23/include/dec/extensions/XieAppl.h:151-157` — the complete set, +five values, nothing else: + +```c + /* + ** Compression Schemes + */ +#define XieK_PCM 0 /* uncompressed */ +#define XieK_G31D 1 /* CCITT Group 3, one-dimensional */ +#define XieK_G32D 2 /* CCITT Group 3, two-dimensional */ +#define XieK_G42D 3 /* CCITT Group 4 */ +#define XieK_DCT 4 /* JPEG - 2D discrete cosine transform */ +``` + +`XieK_DCT` is the JPEG scheme: the man page says of the `cmpprm` argument that +it "specifies a parameter required **for the DCT compression scheme**" +(`man/XieGetImage.3X:56`, `man/XieSetStream.3X:68`). There is no `XieK_JPEG` +and no TIFF/RLE/LZW/PackBits constant anywhere in the 2.3 headers. + +The scheme travels in the SetTransport request as a byte plus a parameter word +(`XieProto.h:538-548`): + +```c +typedef struct { + ... + CARD32 compression_parameter; + CARD8 compression_scheme; + CARD8 mode; + ... +``` + +## What the DEC 2.3 server actually accepts + +`server/xie/XieTransport.c`, `ProcSetTransport` (line 616 onward) validates the +scheme per image: + +```c + switch( stuff->compression_scheme ) + { /* verify compression_scheme */ + case XieK_PCM : break; + case XieK_G31D : + case XieK_G32D : + case XieK_G42D : + MatchOkIf_( IsBitonal_(img) && stuff->mode != XieK_Tile, ...); + case XieK_DCT : + MatchOkIf_(!IsBitonal_(img) && stuff->mode != XieK_Tile + && org != XieK_BitByPlane, ...); + default: BadValue_(stuff->photo_id); + } +``` + +So, concretely: + +* **PCM** — always allowed. +* **G31D / G32D / G42D** — require a **bitonal** image and a mode other than + `XieK_Tile` (i.e. PutStream/GetStream, not PutTile/Tile). +* **DCT (JPEG)** — requires a **non-bitonal** image, a mode other than + `XieK_Tile`, and a component organization other than `XieK_BitByPlane`. +* Anything else — `BadValue`. + +In the transport *implementation* (`ProcGetStream`, line 275 onward) only three +schemes are real, and two are stubs: + +```c + case XieK_DCT : ... s = DdxEncodeDct_( &Udp_(img,p), ... ); break; + case XieK_G42D : ... s = DdxEncodeG4_( Udp_(img,p), ... ); break; + case XieK_PCM : ... break; + case XieK_G31D : /* not yet supported */ + case XieK_G32D : /* not yet supported */ + default : s = BadValue; +``` + +Same stub pair in `ProcSetStream` (line 1460). The DCT and G4 work is delegated +to the DDX hooks `DdxEncodeDct_` / `DdxEncodeG4_` — i.e. to the image +accelerator on the board, which is why the firmware's DDX render path reports +`DDX_RENDER: unsupported compression scheme` when it cannot service one. + +**This is why our working client must use `XieK_PCM`.** It sends a bitonal +64x64 photomap in `mode = XieK_Tile`, and under the rules above that combination +admits PCM only — G3/G4 are refused for Tile mode, and DCT is refused for a +bitonal image. Requesting anything else returns `BadValue`, which is the +`BadValue (integer parameter out of range)` seen in the early runs; `BadMatch` +has the same origin, since these are `MatchOkIf_` checks. + +## X Consortium X11R6.1 — a different, larger list + +`xc/include/extensions/XIE.h:175-206` (the `xieperf` lineage, not what the +VT1200 runs) uses DecodeTechnique / EncodeTechnique enums with ten codecs: + +| constant | value | meaning | +|---|---|---| +| `xieValDecodeUncompressedSingle` | 2 | bitonal & grayscale | +| `xieValDecodeUncompressedTriple` | 3 | colour | +| `xieValDecodeG31D` | 4 | FAX | +| `xieValDecodeG32D` | 6 | FAX | +| `xieValDecodeG42D` | 8 | FAX | +| `xieValDecodeJPEGBaseline` | 10 | grayscale & colour | +| `xieValDecodeJPEGLossless` | 12 | grayscale & colour | +| `xieValDecodeTIFF2` | 14 | TIFF modified G31D | +| `xieValDecodeTIFFPackBits` | 16 | TIFF Apple format | + +So JPEG appears in **both** lineages — as `XieK_DCT` (2.3, one value) and as +JPEG baseline/lossless (X11R6.1, two values) — but the 2.3 protocol that the +terminal speaks has only the single Scheme-4 DCT code, with no baseline/lossless +split and no lossless predictor field in the wire struct. + +## Cross-reference: the DTJ article + +`docs/dec/DTJ-1991-v03-04-bitonal-image-accelerators.pdf` — "Hardware +Accelerators for Bitonal Image Processing" (Payson, Cianciolo, Crouse, Winsor; +DTJ Vol. 3 No. 4, Fall 1991). Reading it against the headers above: + +* The accelerator ASIC it describes is **bitonal** and is a CCITT decoder: "The + decompressor chip acts as a CCITT binary image decoder", converting Huffman + codes to fixed-length codes, and it covers G3-1D, G3-2D and G4-2D. The chip + set is decompressor + scaler (M:N, 1..127) + rotator — the + "scalution" hardware the firmware drives. +* JPEG is discussed in the **continuous-tone** section of the same article, not + as part of that ASIC: "for gray-scale and color images, the Joint + Photographic Experts Group (JPEG) standard"; "the JPEG compression method is + based on the two-dimensional (2D) discrete cosine transform (DCT)". For + hardware it cites C-Cube's **CL550-10 JPEG Image Compression Processor**, not + the bitonal chip. +* The DECimage 1200 terminal (the image-capable sibling of this unit) is + described as using this hardware: "The DECimage 1200 can read, transport, + decompress, scale, and display an 8.5-by-11-inch bitonal document in 1 to 2 + seconds." + +So the article's "image board" is the bitonal G3/G4 decompressor, and JPEG/DCT +is the scheme XIE defines for the continuous-tone data type that the same +protocol carries — the two correspond exactly to `XieK_G42D` and `XieK_DCT`.