# Invoke Confidence Test (DECTST)

> Run the terminal's own self-tests, after which nothing about its state can be relied on.

- **Sequence:** `CSI 4 ; Ps … y`
- **Defaults:** Ps = 0, all tests
- **DEC STD 070:** [§D.4 Test, p. D-11](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n1197/mode/1up)
- **VT510:** [DECTST—Invoke Confidence Test](https://vt100.net/docs/vt510-rm/DECTST.html)

DECTST asks the terminal to run its diagnostics. In the VT510 manual the
first parameter is always `4`, and each one after it selects a test, so that
several can be run at once:

| `Ps` | Test |
| --- | --- |
| `0` | "All Tests" (1, 2, 3 and 6) |
| `1` | power-up self test |
| `2` | RS-232 port data loopback |
| `3` | printer port loopback |
| `4` | speed select and speed indicator |
| `5` | reserved, no action |
| `6` | RS-232 port modem control line loopback |
| `7` | EIA-423 port loopback |
| `8` | parallel port loopback |
| `9` | repeat the other tests in the parameter string |

DEC STD 070 leaves the tests to each product. It lists DECTST among its
documented exceptions, as `CSI Ps y` with a default of 0, on
[p. D-11](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n1197/mode/1up),
and says what the least a terminal may do is:

> The minimal implementation of this control is to execute the Reset to
> Initial State (RIS) control, and to return a "Device Ready" indicator by
> default.

The "Device Ready" indicator is the answer to a [device status
report](https://control-codes.page/csi/dsr/index.html.md), `CSI 5 n`, which a host sends afterwards to learn how
the tests went. Beyond that, DEC STD 070 promises nothing: "after execution
of this control the state of the device should be considered to be
UNDEFINED. NO RECOVERY IS GUARANTEED WHEN THIS CONTROL IS EXECUTED." So there
is no case for what DECTST does to the screen. Its algorithm starts with
[RIS](https://control-codes.page/esc/ris/index.html.md), but a terminal that runs real tests may leave anything
behind them.

xterm does not implement DECTST. Its parse table sends a control sequence
ending in `y` back to the ground state with nothing done
([`VTPrsTbl.c`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/VTPrsTbl.c#L631)).
The cases follow xterm, as the [sources](https://control-codes.page/sources/index.html.md) page explains: the
parameters are not displayed, and the terminal answers "Device Ready"
afterwards. Those are also all that DEC STD 070 pins down, so a terminal
that did run its tests would pass them too.

## Not in libghostty-vt

libghostty-vt has no case for a control sequence ending in `y`, so it
ignores DECTST, as xterm does. That passes both cases, which check only
what is true whether or not a terminal runs a test.

## Validation

### DECTST-1: The parameters are not displayed

Input, one step per line:

```text
\e[4;1y   # the power-up self test
X
```

Expected screen:

```text
|X____|
cursor 1,2
```

### DECTST-2: Ready afterwards

Input, one step per line:

```text
\e[4;0y   # all tests
\e[5n     # how did they go?
```

Expected screen:

```text
|_____|
reply \e[0n
```

---

This is the Markdown version of <https://control-codes.page/csi/dectst/>. 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>.