# Request Status String (DECRQSS, DECRPSS)

> Ask for the current setting of a function, as the sequence that would set it.

- **Sequence:** `DCS $ q Pt ST`
- **DEC STD 070:** [§5.13.2 Request Selection or Setting, p. 5-196](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n450/mode/1up)
- **VT510:** [DECRQSS—Request Selection or Setting](https://vt100.net/docs/vt510-rm/DECRQSS.html)
- **xterm:** [Device-Control functions](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html)

`DCS $ q Pt ST` asks for the current setting of the function whose final
characters, with any intermediates, are `Pt`: `m` for [SGR](https://control-codes.page/csi/sgr/index.html.md), `r`
for [DECSTBM](https://control-codes.page/csi/decstbm/index.html.md), `SP q` for [DECSCUSR](https://control-codes.page/csi/decscusr/index.html.md). The
answer, DECRPSS, is `DCS Ps $ r D…D ST`, where `D…D` is the sequence that
would set it as it is, without the `CSI`, and `Ps` is `1` if the request was
understood and `0` if not. One function per request.

DEC STD 070 gives `Ps` that way round, `1` for success, on the DECRPSS page
([p. 5-197](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n451/mode/1up));
the VT510 manual has them the other way, and xterm, esctest2 and
libghostty-vt all follow DEC STD 070. The [DCS](https://control-codes.page/esc/dcs/index.html.md) page has more on
how the string is parsed.

DEC STD 070 lists what a VT420 reports. A default xterm, a VT420, reports all
of it except the status line, which is not in its default build
([`misc.c`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L4896-L4990)):

| `Pt` | Function | xterm | libghostty-vt |
| --- | --- | --- | --- |
| `m` | [SGR](https://control-codes.page/csi/sgr/index.html.md) | yes | yes |
| `r` | [DECSTBM](https://control-codes.page/csi/decstbm/index.html.md) | yes | yes |
| `s` | [DECSLRM](https://control-codes.page/csi/decslrm/index.html.md) | yes | only with left and right margins enabled |
| `SP q` | [DECSCUSR](https://control-codes.page/csi/decscusr/index.html.md) | yes | yes |
| `" q` | [DECSCA](https://control-codes.page/csi/decsca/index.html.md) | yes | no |
| `" p` | [DECSCL](https://control-codes.page/csi/decscl/index.html.md) | yes | no |
| `t` | DECSLPP | yes | no |
| `$ \|` | [DECSCPP](https://control-codes.page/csi/decscpp/index.html.md) | yes | no |
| `* \|` | [DECSNLS](https://control-codes.page/csi/decsnls/index.html.md) | yes | no |
| `* x` | DECSACE | yes | no |
| `$ }`, `$ ~` | [DECSASD, DECSSDT](https://control-codes.page/csi/decsasd/index.html.md) | no | no |
| `> Pp m` | [XTQMODKEYS](https://control-codes.page/csi/xtmodkeys/index.html.md) | yes | no |

xterm writes an SGR answer in a fixed order: `0`, then bold, underline,
blink, inverse and invisible, then faint, italic, crossed out and double
underline, then the colors, with a color above 15 as `38:5:n` and a direct
color as `38:2::r:g:b`
([`xtermFormatSGR`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L3252-L3320)).
libghostty-vt writes the attributes in numerical order instead, and a
double underline as `4:2`, so those cases are known differences, as are the
settings it does not report. DECSLPP's answer is xterm's as it is: it never
reports fewer than 24 lines.

## Validation

### DECRQSS-1: SGR

Input, one step per line:

```text
\e[3;1m   # italic, bold
\eP$qm\e\\
```

Expected screen:

```text
|______|
reply \eP1$r0;1;3m\e\\
```

### DECRQSS-2: SGR colors

Input, one step per line:

```text
\e[38;5;196;43m
\eP$qm\e\\
\e[0;91;104m
\eP$qm\e\\
\e[0;38;2;1;2;3m
\eP$qm\e\\
```

Expected screen:

```text
|______|
reply \eP1$r0;38:5:196;43m\e\\\eP1$r0;91;104m\e\\\eP1$r0;38:2::1:2:3m\e\\
```

### DECRQSS-3: SGR attributes in xterm's order

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\e[1;2;3;4;5;7;8;9m
\eP$qm\e\\
```

Expected screen:

```text
|______|
reply \eP1$r0;1;4;5;7;8;2;3;9m\e\\
```

### DECRQSS-4: Double underline

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\e[21m
\eP$qm\e\\
```

Expected screen:

```text
|______|
reply \eP1$r0;21m\e\\
```

### DECRQSS-5: The margins

Input, one step per line:

```text
\eP$qr\e\\
\e[?69h
\e[2;5s
\eP$qs\e\\
```

Expected screen:

```text
|______|
|______|
reply \eP1$r1;2r\e\\\eP1$r2;5s\e\\
```

### DECRQSS-6: Left and right margins, not enabled

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\eP$qs\e\\
```

Expected screen:

```text
|______|
reply \eP1$r1;6s\e\\
```

### DECRQSS-7: The cursor style

Input, one step per line:

```text
\eP$q\sq\e\\
\e[3\sq
\eP$q\sq\e\\
```

Expected screen:

```text
|______|
reply \eP1$r2\sq\e\\\eP1$r3\sq\e\\
```

### DECRQSS-8: Protection

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\e[1"q
\eP$q"q\e\\
```

Expected screen:

```text
|______|
reply \eP1$r1"q\e\\
```

### DECRQSS-9: The conformance level

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\eP$q"p\e\\
```

Expected screen:

```text
|______|
reply \eP1$r64;1"p\e\\
```

### DECRQSS-10: The page size

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\eP$qt\e\\
\eP$q$|\e\\
\eP$q*|\e\\
```

Expected screen:

```text
|______|
reply \eP1$r24t\e\\\eP1$r80$|\e\\\eP1$r1*|\e\\
```

### DECRQSS-11: The attribute change extent

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\eP$q*x\e\\
```

Expected screen:

```text
|______|
reply \eP1$r0*x\e\\
```

### DECRQSS-12: The status line, which a default xterm does not have

Input, one step per line:

```text
\eP$q$}\e\\
```

Expected screen:

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

---

This is the Markdown version of <https://control-codes.page/dcs/decrqss/>. On that page every validation case runs live in libghostty-vt, the terminal emulation core of Ghostty, compiled to WebAssembly.

The validation cases are written in the notation described in <https://control-codes.page/notation/index.html.md>.
