DECRQTSR Request Terminal State Report

DECRQTSR asks the terminal for a terminal state report, DECTSR: one device control string that holds most of what the host could have set. DECRSTS sends such a report back to restore that state. All three belong to the terminal state interrogation extension, levels 2 and above with the extension and 3 and 4, and DEC STD 070 defines them on consecutive pages:

DECRQTSR’s parameter chooses the report:

“If the terminal does not recognize the type of DECTSR requested, the entire command is ignored.”

What is in a DECTSR is not something a host can rely on. DEC STD 070 says “The format of the data is firmware revision dependent”, and that it should not be expected to stay the same “across firmware revisions or different members of a terminal family”. The data is a string of bytes ending in a two-byte checksum; on the VT420 it is 110 bytes. It leaves out “the contents of the logical display, DRCS, UDK definitions, and Macros”. So there is no case for what DECRQTSR 1 answers: the sources say only that it is a DECTSR, not what is in it.

DECRSTS takes the same kind of data back. Its parameter names the format, and 0 is “illegal, restore ignored”. The terminal checks the checksum first: “If the checksum fails, the entire sequence is ignored”, and if a value inside is invalid the terminal may skip the rest, “parsing until a ST control is encountered”, with “No error indication” returned. The data is meant to be a report the terminal itself produced: “Software should not use DECRSTS to restore a terminal to a saved state unless that state was previously read from the terminal.”

xterm implements none of the three. Its parse table sends CSI $ u back to the ground state with nothing done (VTPrsTbl.c):

CASE_GROUND_STATE,	/* vt420:DECRQTSR */

and its device control strings with $ restore only DECRSPS, DCS Ps $ t, so a DCS Ps $ p is dropped (misc.c). A default xterm therefore ignores all three, and the cases follow it, as the sources page explains. Each case checks something DEC STD 070 says is ignored as well, so the two agree on everything tested here.

Not in libghostty-vt

libghostty-vt has no terminal state report. It does not recognize CSI $ u, and its DCS handler in dcs.zig recognizes tmux control mode, XTGETTCAP (DCS + q) and DECRQSS (DCS $ q) and drops every other device control string, DECRSTS included. The cases pass because it ignores them, as a default xterm does.

Validation

DECRQTSR-1: No report asked for

\e[$u     # Ps left out
\e[0$u

|_____|
reply none

DECRQTSR-2: An unknown report

\e[3$u    # no such report type
X

|X____|
cursor 1,2
reply none

DECRQTSR-3: A restore is not displayed

\eP0$p@@@@@@\e\\   # DECRSTS with Ps 0: illegal, ignored
\eP1$pABCD@@\e\\   # and data the terminal never sent
X

|X____|
cursor 1,2
reply none