# Device Control One and Three (DC1, DC3)
> XON and XOFF: flow control for what the terminal sends, with no effect on the screen.
- **Sequence:** `DC1`
- **ECMA-48:** [§8.3.28 DC1 – Device Control One, p. 38](https://archive.org/details/ecma-48-5th-edition-june-1991/page/n51/mode/1up)
- **DEC STD 070:** [§5.9.1 C0 Control Characters, p. 5-129](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n383/mode/1up)
- **VT510:** [4.2 Control Characters](https://vt100.net/docs/vt510-rm/chapter4.html#S4.2)
ECMA-48 defines DC1 and DC3 (`11` and `13`) loosely, as turning an
"ancillary device" on and off, and notes that "when used for data flow
control" they are "X-ON" and "X-OFF". DC3 is
[ECMA-48 §8.3.30, p. 39](https://archive.org/details/ecma-48-5th-edition-june-1991/page/n52/mode/1up).
A DEC terminal uses them that way, and they act on the terminal's *sending*.
DEC STD 070 says XOFF "causes terminal to stop transmitting all codes except
XOFF and XON", and XON "causes terminal to resume transmitting", in both
cases only "if XOFF handling is enabled". The VT510 manual says the same
when flow control is enabled in its setup. Neither changes anything on the
screen.
xterm's parser table maps both to [`CASE_IGNORE`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/VTPrsTbl.c#L175-L179), and libghostty-vt ignores
them too.
## Validation
### DC1-1: Nothing on the screen
Input, one step per line:
```text
A
\x11 # DC1, XON
B
\x13 # DC3, XOFF
C
```
Expected screen:
```text
|ABC__|
cursor 1,4
reply none
```
### DC1-2: Ignored inside a control sequence
Input, one step per line:
```text
\e[2\x11;3H # CUP, with an XON inside it
X
```
Expected screen:
```text
|_____|
|__X__|
```
---
This is the Markdown version of . 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 .