I hope that no-one merges that code, because it would be baking erroneous control sequences into OpenBSD. Exotic Silicon is making the mistake that we all have made, of getting ITU/IEC T.416 wrong.

Most of the rest of us have been though the process of discovering this error, some years ago, and by now have switched to the correct control sequence that T.416 actually specifies. It requires colons for sub-parameters, and there is a colour space sub-parameter that means that the RGB sub-parameters are actually off by one position in what Exotic Silicon is emitting. There are also sub-parameters that follow the RGB sub-parameters.

Another error in what is done here, and another reason not to merge this code, is the invasion into the standardized space for control sequences when there is a long-standing mechanism for private extensions like this. Exotic Silicon has invented a bogus SGR 128 (with sub-parameters that are not correctly colon-delimited, again) for something that is not even a Graphics Rendition.

There is an accepted extension mechanism for this that has been around since the 1980s: additional parameter characters. Many DEC private control sequences use the question mark as a parameter character to turn (for example) SM and RM into DECSM and DECRM.

SCO did this as well with SCO Multiscreen, one of the precursors of wscons, and SCO's parameter character of choice was the equals sign. There are CSI '=' control sequences, with various final characters, for setting several PC-like things like BEL pitch and duration, overscan colour, and the MC6845 blink/bright bit. They are laid out on the screen(4) manual page.

Setting blink mark/space pattern and frequency fits squarely into SCO's system and cries out for something like CSI '=' n ';' m 'q' .