DECRQCRA Request Checksum of Rectangular Area

Ask the terminal for a checksum of a rectangle of the screen, so that an application can check nothing there has changed behind its back. Pi is a label of the application’s choosing, Pp the page, and Pt, Pl, Pb and Pr the rectangle’s top, left, bottom and right, as for the other rectangle operations. The terminal answers with DECCKSR, DCS Pi ! ~ D…D ST, where D…D is the checksum as four hexadecimal digits (DEC STD 070 p. 5-181, DECCKSR). DEC STD 070 makes it part of level 4’s data integrity features, for transaction processing.

xterm, a VT420 by default, implements it (CASE_DECRQCRA), summing the characters in the rectangle with a value added for each video attribute, skipping blanks at the ends of lines, and negating the total (xtermCheckRect; its checksumExtension resource turns parts of that off). But it answers only when the GetChecksum window operation is allowed, and by default it is not: GetChecksum is in xterm’s default list of disallowed window operations (main.h). So a default xterm sends nothing.

libghostty-vt implements DECRQCRA, and XTCHECKSUM (CSI Ps # y), which chooses the calculation as xterm’s checksumExtension does, following xterm’s xtermCheckRect (xt_checksum.zig). But like xterm it leaves them off, and for the same reason: a program could checksum the screen one cell at a time and so read back everything on it. A host turns them on with GHOSTTY_TERMINAL_OPT_XT_CHECKSUM_REPORT, and sets the calculation with GHOSTTY_TERMINAL_OPT_XT_CHECKSUM_EXTENSION (terminal.h); until then both are ignored (stream_terminal.zig). The first two cases run it as it comes, so it sends nothing, which is what a default xterm does.

The rest run with checksum reports allowed, as the notation page’s checksum-report attribute asks, in xterm and libghostty-vt alike. Both sum the area by default as a DEC terminal does: each character’s code, plus a value for each video attribute in its cell, 0x80 for bold among them, with cells never written to left out, and the total negated to 16 bits. XTCHECKSUM’s bits change that: 1 leaves the total as it is, 2 leaves the attributes out, 4 stops blanks being left out, 8 counts cells never written to as spaces, and 16 uses whole code points rather than DEC’s 8-bit values.

The two differ when the request has only Pi and Pp. DEC STD 070 has the bounds left out default to the whole page, and libghostty-vt sums the whole screen. xterm skips past Pi and Pp only when there are more than two parameters (xtermCheckRect), so with two it reads them as the top and left: CSI 7 ; 1 * y asks for a rectangle starting at line 7, which on a screen of two lines is no rectangle at all, and xterm answers 0000. DECRQCRA-7 follows xterm and is a known difference. With the bounds present but empty, CSI 7 ; 1 ; ; ; ; * y, xterm uses their defaults too.

Support

Validation

DECRQCRA-1: No answer by default

ABC
\e[1;1;1;1;1;3*y

|ABC_______|
reply none

DECRQCRA-2: Nor for the whole screen

ABC
\e[7;1*y

|ABC_______|
|__________|
reply none

DECRQCRA-3: Allowed, the sum of the area, negated

ABC
\e[1;1;1;1;1;3*y

|ABC_______|
reply \eP1!~FF3A\e\\

DECRQCRA-4: A video attribute adds to its cell

\e[1mA\e[0mBC   # A in bold
\e[1;1;1;1;1;3*y

|ABC_______|
reply \eP1!~FEBA\e\\

DECRQCRA-5: Cells never written to are left out

AB
\e[1;1;1;1;1;10*y

|AB________|
reply \eP1!~FF7D\e\\

DECRQCRA-6: XTCHECKSUM 1 leaves the sum as it is

\e[1#y      # don't negate
ABC
\e[1;1;1;1;1;3*y

|ABC_______|
reply \eP1!~00C6\e\\

DECRQCRA-7: With only two parameters, they are the top and left

ABC
\e[7;1*y      # Pt = 7 is off the screen

|ABC_______|
|__________|
reply \eP7!~0000\e\\

DECRQCRA-8: Empty bounds are the whole screen

ABC
\e[7;1;;;;*y

|ABC_______|
|__________|
reply \eP7!~FF3A\e\\