[systemd-devel] vt220 default for serial console still relevant?

[Christopher Cox]

On 7/14/20 4:27 PM, Mantas Mikulėnas wrote:
> On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer <daan.j.demeyer at gmail.com 
> <mailto:daan.j.demeyer at gmail.com>> wrote:
> 
>     I just tried vt241 and didn't get colorized output in konsole. I looked
>     around a bit and it doesn't really seem supported at all by terminal
>     emulators (or at least none that I found). I also tried TERM=xterm-256color
>     with 8 different terminal emulators and got colors with all of them. My
>     workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds
>     console=ttyS0 and overrides TERM for serial-getty at ttyS0 in the vm)." That
>     connects my terminal emulator to the serial console of the vm. I then
>     execute "ls -l --color /" in the vm and get colored output every time in
>     whatever terminal emulator that I try.
> 
>     I'm probably missing something but I'm wondering what an example terminal
>     emulator would be where xterm-256color would not work at all (even st worked
>     perfectly and that is supposed to be pretty barebones afaik). Or is it just
>     that color is a commonly supported subset of xterm and stuff breaks down
>     with other escape codes instead? Or maybe qemu is doing some kind of
>     translation that magically makes every TERM setting work in whatever
>     terminal emulator I try? Apologies if this seems ignorant, I have no
>     experience at all with this domain.
> 
> 
> The basic formatting codes (bold, reverse, 8/16-color) are practically the same 
> everywhere. In fact they're so widespread that many programs and scripts just 
> straight up hardcode them. (xterm, st, etc. are supersets of vt220/vt421 in that 
> regard.)
> 
> But 256-color or even 24-bit-color codes are not as widely supported. The Linux 
> VT has only recently started *recognizing* them (though still maps them down to 
> 8 colors). If you use TERM=xterm-256color with Linux VT, apps can look really 
> weird because you told them they can use these extended color codes even though 
> they cannot.
> 
> Graphical terminal emulators recognize the "update status line" codes (which 
> goes the X11 window titlebar) -- but the Linux VT has no such thing and the same 
> code will just show up as garbage on screen.
> 
> Google tells me VT421 supported sixel graphics. I'm not sure if any programs 
> make use of that nowadays, but if they do, then trying to use TERM=vt421 with a 
> terminal that doesn't do sixel will result in more garbage on screen.
> 
> There are various other differences like this.

Boot up logs should target "dumb" terminal only.

So, in the case of boot logs (where we have no idea where messages are going), 
if you want "color", I'd use some kind of markup and allow to be interpreted by 
whatever is viewing that.

But with regards to logs presumably going to a terminal (real or virtual or 
whatever), I'd lean on terminfo and end user selection (which could be by TERM 
in the case of an established terminal).

And of course, if it's ok for Dell/HP/IBM to assume Hyperterminal (ansi, 80x25) 
for BIOS setup,etc via serial, maybe it's not too far a stretch for Linux to 
assume something.  But IMHO, if at all possible, I'd make this configurable and 
again, lean on terminfo.

Personally I like log data that is parseable.  And data with a gazillion escape 
sequences is very noisy to look at.  Perhaps another reason for some sort of 
simple markup instead of escape sequences (?).  Hey, our developers are 
constantly hard coding ansi-escapes into their log messages so they look 
"pretty" in very very specific viewers.  Not the way I'd handle it.