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

[Michał Zegan]

Note there is an easy way to override term type.
The default serial-getty at .service at least here has no TERM set by
default, but uses it to set term type when launching getty.
You can use kernel command line and add TERM=screen for example, or
things like that, and it should be picked up, shouldn't it?
W dniu 15.07.2020 o 00:44, Christopher Cox pisze:
> 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.
> 
> 
> 
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200715/d0d5ed18/attachment.sig>