DCS Device Control String

DCS opens a control string of commands for the terminal, closed by ST. ECMA-48 leaves the format of the commands to the devices involved. DEC STD 070 gives the one DEC terminals use: a parameter string, intermediates and a final byte, exactly like a control sequence’s, followed by the data, D…D, and ST. The final byte is always one of the private ones, p to ~. DEC uses device control strings for loading character sets, user-defined keys and sixel graphics, and for asking about settings.

Nothing in a device control string is displayed. One the terminal does not implement is thrown away whole, from DCS to ST, “without being displayed” (DEC STD 070 §3.5.4.6, p. 3-30).

Ending early. On the same page, DEC STD 070 lets CAN, SUB, ESC or any C1 control end a control string too, “to minimize the effect of a lost String Terminator”, though software should not rely on it. The format effectors BS to CR may appear in the data, and it recommends that any other control be ignored. So BEL neither ends a device control string nor rings in one in libghostty-vt. xterm, which only lets BEL end an OSC, rings the bell for one inside a DCS and carries on (CASE_BELL).

Request Status String. One device control string libghostty-vt does answer is DECRQSS, DCS $ q Pt ST, which asks for the current setting of the function Pt names: m for SGR, r for the top and bottom margins, and others. The answer, DECRPSS, is DCS Ps $ r D…D ST, where D…D is the setting written as the sequence that would set it. The VT510 manual’s DECRPSS page gives Ps as 0 for a valid request and 1 for an invalid one, but xterm answers 1 for valid and 0 for invalid, its Control Sequences document says so, and esctest2’s decrqss.py expects it. libghostty-vt answers as xterm does.

xterm adds three more of its own, which libghostty-vt answers only in part: XTGETTCAP, DCS + q, which asks what a key sends; XTSETTCAP, DCS + p; and XTGETXRES, DCS + Q, which asks for its settings.

DCS is a C1 control. ECMA-48 also defines it as the single byte 90, which libghostty-vt, decoding its input as UTF-8, does not accept.

Support

Validation

DCS-1: Not displayed

A
\eP1;2zhello\e\\   # a DCS libghostty-vt does not implement
B

|AB____|
cursor 1,3
reply none

DCS-2: Asking for the rendition

\e[1;91m  # bold, bright red
\eP$qm\e\\

|______|
reply \eP1$r0;1;91m\e\\

DCS-3: Asking for the margins

\e[2;3r
\eP$qr\e\\

|______|
|______|
|______|
reply \eP1$r2;3r\e\\

DCS-4: A request it does not understand

\eP$qz\e\\

|______|
reply \eP0$r\e\\

DCS-5: ESC or CAN ends it early

A
\ePzhi    # never terminated
\e[2;2H   # the ESC ends the string, and this is a CUP
B
\ePzhi\x18   # CAN ends it too
C

|A_____|
|_BC___|

DCS-6: BEL does not end it, but rings

A
\ePzhi\a  # BEL rings, and the string goes on
B         # so this is part of it
\e\\
C

|AC____|
bell 1