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

[Matwey V. Kornilov]

Dear all,

I've just read the discussion with a great interest. What I would like
to add is that there a people (like me) who use real world serial
consoles (not emulated as in qemu) for working with ARM single board
computers.

I usually use 'screen' terminal emulator to connect to /dev/ttyUSB0 or
so. `screen' itself is running in Konsole (which is TERM=xterm).
As far as I understand, 'screen' currently understands some set of vt2xx
commands (coming from rs232 console) and converts them to render in
xterm somehow. But I am not sure if it will still work correctly for
other kind of term.


11.07.2020 19:51, Daan De Meyer пишет:
> Hi,
> 
> I was playing around with mkosi's qemu support, more specifically adding
> the -nographic option to have the virtual machine output in my terminal
> instead of a separate window. After figuring out that I had to add
> console=ttyS0 to mkosi's kernel command line, I got the output from the vm
> in my terminal as expected. However, because systemd defaults to TERM=vt220
> for serial consoles, the output is not colorized. I searched around a bit
> and found that this is done for compatibility reasons. Will there ever be a
> point where we can switch the default to something that supports colors
> (like TERM=linux)?
> 
> I managed to get around the problem by overriding serial-getty@ttyS0 and
> setting Environment=TERM=linux explicitly but it's a bit of a pain and has
> to be added to every rootfs that wants to support colored output on its
> serial console.
> 
> Cheers,
> 
> Daan
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mo, 20.07.20 10:13, Bruce A. Johnson (bjohn...@blueridgenetworks.com) wrote:

> Reading this discussion about VT220, I'm wondering why that was the
> choice and not VT100 (which was also monochrome). And I'm straining my
> memory to recall what it was that we had back then that made the VT100
> seem so slick and futuristic.

Our default used to be vt100 originally, but that can't do
pgup/pgdown, which people found quite annyoing. vt220 adds support for
that, and is apparently as widely supported, so we changed to that.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mo, 20.07.20 15:03, s...@collabora.com (s...@collabora.com) wrote:

> On Sat, 11 Jul 2020 at 21:04:18 +0200, Lennart Poettering wrote:
> > widely-supported TERM value
>
> For a value of TERM to work (at all), it must be something that is reliably
> present in the terminfo/termcap data visible to TUI programs.
>
> Debian divides terminfo into two categories. It wouldn't surprise me
> if other distributions have a similar split, with the line drawn in a
> different place.
>
> ncurses-base is marked as Essential (so every Debian system is required
> to have it) and supports a relatively small number of common terminals:
> https://packages.debian.org/sid/all/ncurses-base/filelist
> (In particular this includes linux, vt220, xterm, xterm-256color, ansi,
> screen and tmux.)

So what I find interesting: it lists vt300 too, but vt300 is a series
of terminals, and the first model in the series is apparently vt320,
followed by vt330, and vt340, where the latter added color. Now, if
the whole series is grouped under one moniker "vt300" (and there's no
model named like that), it sounds like one could convince people to
enable color for that...

I think what's interesting to ask is not whether some terminal type
such as vt100 or vt220 actually do color, but whether they gracefully
handle color sequences. i.e. if I send color sequences to the original
vt100, what happens? does it spew them as weird characters onto the
screen, or does it simply ignore it? What about the vt220? Because, if
they all just take it and ignore it, there's a good case to be made to
convince "ls" and such tools to just enable color for them, since it
has no effect if connected to an actual vt100/vt220 terminal, but
works wonders for everyone else...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Bruce A. Johnson]

Reading this discussion about VT220, I'm wondering why that was the
choice and not VT100 (which was also monochrome). And I'm straining my
memory to recall what it was that we had back then that made the VT100
seem so slick and futuristic.

Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com

On 13/07/2020 17:08, Barry wrote:
>
>
>> On 11 Jul 2020, at 20:31, Daan De Meyer  wrote:
>>
>> 
>> > TERM=linux means Linux console, but that's just too much, as it not
>> > only implies a multitude of ESC sequences specific to the Linux
>> > console, but also indicates that certain ioctls might work. In our own
>> > code we also bind certain behaviour to TERM=linux, as indicator if we
>> > are on the Linux console.
>> >
>> > I am not aware of any widely-supported TERM value that would be a
>> > reasonable subset of all currently used terminals and does color.
>>
>> I did some more research and it turns out VT220 does support colors.
>> My terminal emulator (Konsole) just doesn't seem to support it. I
>> installed xterm (which explicitly advertises support for VT220 escape
>> codes) and got colored output as expected.  I guess this means it's
>> up to Konsole to support more of VT220 if I want this to work
>> seamlessly (or I switch terminals to xterm).
>>
>
> No vt220 does not support colour. I used to work on one and it is
> monochrome hardware.
> Xterm and konsole support extensions beyond vt220 that add in the
> colour support.
>
> Barry
>
>> Thanks for the extra info and context.
>>
>> Daan
>>
>> On Sat, 11 Jul 2020 at 20:04, Lennart Poettering
>> mailto:lenn...@poettering.net>> wrote:
>>
>> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com
>> ) wrote:
>>
>> > Hi,
>> >
>> > I was playing around with mkosi's qemu support, more
>> specifically adding
>> > the -nographic option to have the virtual machine output in my
>> terminal
>> > instead of a separate window. After figuring out that I had to add
>> > console=ttyS0 to mkosi's kernel command line, I got the output
>> from the vm
>> > in my terminal as expected. However, because systemd defaults
>> to TERM=vt220
>> > for serial consoles, the output is not colorized. I searched
>> around a bit
>> > and found that this is done for compatibility reasons. Will
>> there ever be a
>> > point where we can switch the default to something that
>> supports colors
>> > (like TERM=linux)?
>>
>> TERM=linux means Linux console, but that's just too much, as it not
>> only implies a multitude of ESC sequences specific to the Linux
>> console, but also indicates that certain ioctls might work. In
>> our own
>> code we also bind certain behaviour to TERM=linux, as indicator if we
>> are on the Linux console.
>>
>> I am not aware of any widely-supported TERM value that would be a
>> reasonable subset of all currently used terminals and does color.
>>
>> > I managed to get around the problem by overriding
>> serial-getty@ttyS0 and
>> > setting Environment=TERM=linux explicitly but it's a bit of a
>> pain and has
>> > to be added to every rootfs that wants to support colored
>> output on its
>> > serial console.
>>
>> Unfortunately we can't guess the right terminal, we cannot propagate
>> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
>> from a Linux console, hence the best thing we can do is stick to a
>> reasonably powerful subset that is likely going to exist everywhere,
>> and that's vt220 right now, as noone had a better suggestion so
>> far...
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[smcv]

On Sat, 11 Jul 2020 at 21:04:18 +0200, Lennart Poettering wrote:
> widely-supported TERM value

For a value of TERM to work (at all), it must be something that is reliably
present in the terminfo/termcap data visible to TUI programs.

Debian divides terminfo into two categories. It wouldn't surprise me
if other distributions have a similar split, with the line drawn in a
different place.

ncurses-base is marked as Essential (so every Debian system is required
to have it) and supports a relatively small number of common terminals:
https://packages.debian.org/sid/all/ncurses-base/filelist
(In particular this includes linux, vt220, xterm, xterm-256color, ansi,
screen and tmux.)

ncurses-term is not Essential (so it will be missing from minimal
systems), and contains the complete menagerie, including many historical
serial terminals.

> stick to a reasonably powerful subset

It might be useful to observe that there are two possible levels
of compliance with particular terminal escape codes: "does the right
thing" and "doesn't do the wrong thing". My understanding is that the
ANSI terminal spec is sufficiently general that a terminal emulator can
gracefully degrade by treating certain equivalence classes of terminal
escape as "do nothing", for example accepting but ignoring colours.

smcv
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daan De Meyer]

> Well, --color means you request color no matter what, so this is not
surprising.

I actually only got color because TERM was set to xterm-256color. ls won't
output color if TERM is set to vt220. It checks against a hardcoded list of
terminals to determine whether it'll output colors or not. See
https://github.com/coreutils/coreutils/blob/6a3d2883fed853ee01079477020091068074e12d/src/dircolors.hin

> Again, I'd be happy to switch to a different default for serial
> terminals if we can find a reasonable one that is available widely in
> termcap, that does color, and is a subset of both TERM=linux and
> TERM=xterm.

So the vt220 was the first of the vt200 series and was a black and white
terminal. The vt241 was the model in that series that added colors. Problem
is that the vt241 is not in my terminfo database. The other problem is that
vt241 is not actually in ls's list of terminals that it should output
colors for so using that one is probably not a good idea. What would work
is vt100 since for some weird reason that one is in ls's list of terminals
with colors even though
https://invisible-island.net/ncurses/ncurses.faq.html#vt100_color
explicitly says the vt100 does not support colors. Switching to vt100 would
break pageup/pagedown however so that's not really an option either. I
didn't find any other alternatives that seemed viable.

I suppose I could make a coreutils PR that adds vt220 to the list of
terminals that support colors. vt100 is already in there and it doesn't
support colors so who knows maybe they'll add vt220 as well for the
pragmatic reason that systemd can't use anything else but it would still be
nice to have colors out of the box. I don't think that's likely to be
accepted though and it only fixes ls and not programs like ncurses which
adhere to whatever's in the terminfo database.

For now, the pragmatic solution for my use case (mkosi test VMs that only I
will ever use) is to simply make it easy to override TERM in the VM to
whatever TERM is in my host terminal via mkosi.

Daan




On Wed, 15 Jul 2020 at 17:09, Lennart Poettering 
wrote:

> On Di, 14.07.20 22:15, Daan De Meyer (daan.j.deme...@gmail.com) wrote:
>
> > > About your other comments, systemd sits in user space and can query
> > (depend
> > > upon) terminfo.  Then, it should be able to support "whatever" terminfo
> > has
> > > defined which could include custom terminals by the way that an end
> > user has
> > > added.  And while all of that sounds incredibly ancient/old, I was on a
> > project
> > > post 2000 that had to do exactly that (of course, even that might sound
> > too old).
> >
> > Interestingly enough, systemd's colors work even when TERM is set to
> vt220,
> > probably because it uses ansi escape codes regardless of the TERM
> setting.
> > I think there's probably lots of applications doing this except for ls in
> > coreutils which has an explicit list of terminals with color support
> > encoded in the dircolors configuration file.  If TERM isn't one of those,
> > you don't get colors. There's probably others that do this as well. I
> don't
> > think changing the default in systemd is a good idea since it might break
> > other stuff. I'm going to submit a mkosi PR instead that adds an option
> > that overrides serial-getty@ttyS0 with whatever terminal the user wants.
> > Colors won't work out of the box but at least it shouldn't be too hard to
> > find out how to get them to work when using mkosi.
>
> Again, I'd be happy to switch to a different default for serial
> terminals if we can find a reasonable one that is available widely in
> termcap, that does color, and is a subset of both TERM=linux and
> TERM=xterm.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Di, 14.07.20 22:15, Daan De Meyer (daan.j.deme...@gmail.com) wrote:

> > About your other comments, systemd sits in user space and can query
> (depend
> > upon) terminfo.  Then, it should be able to support "whatever" terminfo
> has
> > defined which could include custom terminals by the way that an end
> user has
> > added.  And while all of that sounds incredibly ancient/old, I was on a
> project
> > post 2000 that had to do exactly that (of course, even that might sound
> too old).
>
> Interestingly enough, systemd's colors work even when TERM is set to vt220,
> probably because it uses ansi escape codes regardless of the TERM setting.
> I think there's probably lots of applications doing this except for ls in
> coreutils which has an explicit list of terminals with color support
> encoded in the dircolors configuration file.  If TERM isn't one of those,
> you don't get colors. There's probably others that do this as well. I don't
> think changing the default in systemd is a good idea since it might break
> other stuff. I'm going to submit a mkosi PR instead that adds an option
> that overrides serial-getty@ttyS0 with whatever terminal the user wants.
> Colors won't work out of the box but at least it shouldn't be too hard to
> find out how to get them to work when using mkosi.

Again, I'd be happy to switch to a different default for serial
terminals if we can find a reasonable one that is available widely in
termcap, that does color, and is a subset of both TERM=linux and
TERM=xterm.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Di, 14.07.20 19:48, Daan De Meyer (daan.j.deme...@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@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.

Well, --color means you request color no matter what, so this is not surprising.

> 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

xterm-256color is a relatively "recent" definition, actually.

The thing is that xterm has ton of extensions in the set of ANSI/CSI
sequences that for example the Linux console does not have. Hence it
sucks advertising the Linux console as xterm. Similar, the Linux
console has a lot of different semantics and features beyond
xterm. And even besides the command set there's other stuff context
derived from the terminal setting. For example in systemd we disable
emojis if TERM=linux is set, since we know that the linux console has
only mininmal unicode support, i.e. 512 glyphs at max, and emojis are
almost certainly not among them. Terminals after all don't advertise
the set of glyphs they can display, so the second best thing is to
trust TERM=linux. (We also turn off emojis on TERM=dumb)

> 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.

Pretty much all current terminal emulators support color just
fine. It's really old legacy hw terminals that don't support that.

In systemd we don't really care much about super old terminal support,
i.e. we never consult termcap/terminfo about terminals, because we
don't want to require that to be installed. Instead, we assume that
terminals can do color, except if TERM=dumb is set, it's 2020 after
all. We also assume they can do full Unicode, except if LC_CTYPE is
configured and explicitly indicates otherwise. We assume they can do
emojis, except if TERM=linux or TERM=dumb is set where we know it's
not supported. And we assume that hyperlinks work (except if "less" is
involved). I think assuming this all to just work on any recent
terminal is pretty safe in 2020. Of course this means we might
mistakenly output color sequences to a 1980's terminal if you actually
connect that, but besides some exotic hackers noone does that anymore,
hence we don't really care (and noone ever filed a bug about
that). You can turn off color, unicode, emoji support individually via
env vars btw, if people really want compat with such old terminals.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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@.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
>> mailto:daan.j.deme...@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@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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 > 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@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mantas Mikulėnas]

On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer 
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@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.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daan De Meyer]

> About your other comments, systemd sits in user space and can query
(depend
> upon) terminfo.  Then, it should be able to support "whatever" terminfo
has
> defined which could include custom terminals by the way that an end
user has
> added.  And while all of that sounds incredibly ancient/old, I was on a
project
> post 2000 that had to do exactly that (of course, even that might sound
too old).

Interestingly enough, systemd's colors work even when TERM is set to vt220,
probably because it uses ansi escape codes regardless of the TERM setting.
I think there's probably lots of applications doing this except for ls in
coreutils which has an explicit list of terminals with color support
encoded in the dircolors configuration file.  If TERM isn't one of those,
you don't get colors. There's probably others that do this as well. I don't
think changing the default in systemd is a good idea since it might break
other stuff. I'm going to submit a mkosi PR instead that adds an option
that overrides serial-getty@ttyS0 with whatever terminal the user wants.
Colors won't work out of the box but at least it shouldn't be too hard to
find out how to get them to work when using mkosi.

Thanks for all the info as well. It's always fun to read how stuff was done
back in the early days.

Daan

On Tue, 14 Jul 2020 at 21:04, Christopher Cox  wrote:

> On 7/14/20 1:48 PM, Daan De Meyer 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@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.
>
> So, some info (not necessarily direction).  Old guys like to talk...
>
> So, speaking of things of old, but not ancient old, when handling server
> equipment via serial, you normally do three things.  You route the BIOS
> (legacy)
> out the serial port, you send the kernel boot messages out the serial port
> and
> you establish a getty for login on the serial port.
>
> Just being honest, the "server world" decided everything was Microsoft
> Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25)
> during the PC revolution.
>
> So.. Windows doesn't come with Hyperterminal anymore, which makes sense
> since
> PCs in general don't have serial ports (apart from USB-serial dongles).
>
> So, can you, or should you adopt a serial console solution (ansi, 80x25)?
> IMHO,
> this is still interesting.  Especially in the Linux world.  Consider that
> network equipment still speaks serial for console, the concept (still,
> even
> though this in a old concept) of using, for example, ssh to serial console
> controllers for full out of band access might still be appealing.
>
> Why?  Well, for many reasons.  Cabling is much less (that is, less dense)
> as you
> can use flat velum for quite some distance for serial.  Since you're
> having to
> somehow deal with network devices anyway, by have all done serially, you
> have
> "one stop" shopping for out of band (more on this in a bit) console access.
>
> Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But
> noting
> that you don't get virtual media with a serial console head solution
> either.
>
> But still, if running remote facilities and you need true out of band, and
> by
> that I mean the ability to reconfigure everything, including the network,
> it
> could be just the thing you need.
>
> But ssh? Network reconfigure?  That's not going to work.  Often times
> those same
> ssh to serial console devices have additional serial support usually with
> a
> option of a modem (yep... old school I know).  Back in the day, using a
> callback
> modem (added security) your infrastructure could reach out to you and you
> could
> indeed reconfigure the whole datacenter, soup to nuts.  Something lacking
> in
> general today.
>
> About your other comments, systemd sits in user space and can query
> (depend
> upon) terminfo.  Then, it should 

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

[Christopher Cox]

On 7/14/20 1:48 PM, Daan De Meyer 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@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.


So, some info (not necessarily direction).  Old guys like to talk...

So, speaking of things of old, but not ancient old, when handling server 
equipment via serial, you normally do three things.  You route the BIOS (legacy) 
out the serial port, you send the kernel boot messages out the serial port and 
you establish a getty for login on the serial port.


Just being honest, the "server world" decided everything was Microsoft 
Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) 
during the PC revolution.


So.. Windows doesn't come with Hyperterminal anymore, which makes sense since 
PCs in general don't have serial ports (apart from USB-serial dongles).


So, can you, or should you adopt a serial console solution (ansi, 80x25)?  IMHO, 
this is still interesting.  Especially in the Linux world.  Consider that 
network equipment still speaks serial for console, the concept (still, even 
though this in a old concept) of using, for example, ssh to serial console 
controllers for full out of band access might still be appealing.


Why?  Well, for many reasons.  Cabling is much less (that is, less dense) as you 
can use flat velum for quite some distance for serial.  Since you're having to 
somehow deal with network devices anyway, by have all done serially, you have 
"one stop" shopping for out of band (more on this in a bit) console access.


Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But noting 
that you don't get virtual media with a serial console head solution either.


But still, if running remote facilities and you need true out of band, and by 
that I mean the ability to reconfigure everything, including the network, it 
could be just the thing you need.


But ssh? Network reconfigure?  That's not going to work.  Often times those same 
ssh to serial console devices have additional serial support usually with a 
option of a modem (yep... old school I know).  Back in the day, using a callback 
modem (added security) your infrastructure could reach out to you and you could 
indeed reconfigure the whole datacenter, soup to nuts.  Something lacking in 
general today.


About your other comments, systemd sits in user space and can query (depend 
upon) terminfo.  Then, it should be able to support "whatever" terminfo has 
defined which could include custom terminals by the way that an end user has 
added.  And while all of that sounds incredibly ancient/old, I was on a project 
post 2000 that had to do exactly that (of course, even that might sound too old).


Btw, as weird as it sounds, where I work today, and I'm not the network admin, 
the network admin has purchased a ssh to serial console controller with callback 
modem.  And he's in his early 30's.


Btw, when I used to help manage an entire datacenter (same time as contract 
below) with those ssh to serial controllers, I just let the the linux TERM 
remain as it was mostly compatible with the ANSI from the host BIOS (at least 
I'm pretty sure).


With regards to that post 2000 project, I was interfacing with an old accounting 
package called datamodes.  Company wanted a solution where by people at home 
could ssh into this character based gui, have all the key sequences (and I do 
mean all, every Fn, Ctrl, Shift, Alt combo) and have the ability to print to 
their local printers from that ssh terminal session.  All of this was doable 
with good old fashioned terminal handling from the ancient of days.  But I did 
have to craft my own terminfo entry.  Loosely based off the scoansi terminal 
(one of the most complete terminal definitions out there, but not totally 
complete).  The end users were already running a terminal emulator that had a 
SCO ansi mode.


(even back then, datamodes had a "Windows" 

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

[Daan De Meyer]

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@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.

Daan

On Tue, 14 Jul 2020 at 18:22, Christopher Cox  wrote:

> On 7/14/20 3:19 AM, Lennart Poettering wrote:
> > On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:
> >
> >>> No vt220 does not support colour. I used to work on one and it is
> >>> monochrome hardware.
> >>> Xterm and konsole support extensions beyond vt220 that add in the
> colour support.
> >>
> >> Not sure how much (offtopic) history we want to get into.  I used the
> VT240
> >> in my college graphics class.  The VT241 was the color variant.
> >>
> >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
> >>
> >> I still meet programmers what hard code ansi sequences rather than
> querying
> >> termcap/terminfo.  You know what they say about those who "assume".
> >
> > Hmm, if vt241 is a bettre featured terminal type, and both xterm and
> > the Linux console a superset of it, and the terminal widely available
> > in termcaps and stuff we can certainly change our default TERM to be
> > vt241.
> >
> > Daan, if this all is the case, could you prep a PR?
>
> I would think shooting for something low is actually good.  Let the
> individual
> configure for something "better".
>
> I'm not sure I'm ready to say monochrome is obsolete.  There can be beauty
> in
> simplicity and function.  My preference, aim low, and allow easy
> configuration
> upward.  You could take the opposite stance of course, it's just that it
> could
> cause some frustration.
>
> Just my opinion though.  I'm old and I think about a lot of things like
> terminals, "proxies" and callback modems... things of value, but most do
> not
> understand or care about anymore.
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Christopher Cox]

On 7/14/20 3:19 AM, Lennart Poettering wrote:

On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:


No vt220 does not support colour. I used to work on one and it is
monochrome hardware.
Xterm and konsole support extensions beyond vt220 that add in the colour 
support.


Not sure how much (offtopic) history we want to get into.  I used the VT240
in my college graphics class.  The VT241 was the color variant.

See: http://terminals-wiki.org/wiki/index.php/DEC_VT240

I still meet programmers what hard code ansi sequences rather than querying
termcap/terminfo.  You know what they say about those who "assume".


Hmm, if vt241 is a bettre featured terminal type, and both xterm and
the Linux console a superset of it, and the terminal widely available
in termcaps and stuff we can certainly change our default TERM to be
vt241.

Daan, if this all is the case, could you prep a PR?


I would think shooting for something low is actually good.  Let the individual 
configure for something "better".


I'm not sure I'm ready to say monochrome is obsolete.  There can be beauty in 
simplicity and function.  My preference, aim low, and allow easy configuration 
upward.  You could take the opposite stance of course, it's just that it could 
cause some frustration.


Just my opinion though.  I'm old and I think about a lot of things like 
terminals, "proxies" and callback modems... things of value, but most do not 
understand or care about anymore.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:

> > No vt220 does not support colour. I used to work on one and it is
> > monochrome hardware.
> > Xterm and konsole support extensions beyond vt220 that add in the colour 
> > support.
>
> Not sure how much (offtopic) history we want to get into.  I used the VT240
> in my college graphics class.  The VT241 was the color variant.
>
> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
>
> I still meet programmers what hard code ansi sequences rather than querying
> termcap/terminfo.  You know what they say about those who "assume".

Hmm, if vt241 is a bettre featured terminal type, and both xterm and
the Linux console a superset of it, and the terminal widely available
in termcaps and stuff we can certainly change our default TERM to be
vt241.

Daan, if this all is the case, could you prep a PR?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Christopher Cox]

On 7/13/20 4:08 PM, Barry wrote:




On 11 Jul 2020, at 20:31, Daan De Meyer  wrote:


> TERM=linux means Linux console, but that's just too much, as it not
> only implies a multitude of ESC sequences specific to the Linux
> console, but also indicates that certain ioctls might work. In our own
> code we also bind certain behaviour to TERM=linux, as indicator if we
> are on the Linux console.
>
> I am not aware of any widely-supported TERM value that would be a
> reasonable subset of all currently used terminals and does color.

I did some more research and it turns out VT220 does support colors. My 
terminal emulator (Konsole) just doesn't seem to support it. I installed xterm 
(which explicitly advertises support for VT220 escape codes) and got colored 
output as expected.  I guess this means it's up to Konsole to support more of 
VT220 if I want this to work seamlessly (or I switch terminals to xterm).




No vt220 does not support colour. I used to work on one and it is monochrome 
hardware.

Xterm and konsole support extensions beyond vt220 that add in the colour 
support.


Not sure how much (offtopic) history we want to get into.  I used the VT240 in 
my college graphics class.  The VT241 was the color variant.


See: http://terminals-wiki.org/wiki/index.php/DEC_VT240

I still meet programmers what hard code ansi sequences rather than querying 
termcap/terminfo.  You know what they say about those who "assume".


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Barry]

> On 11 Jul 2020, at 20:31, Daan De Meyer  wrote:
> 
> 
> > TERM=linux means Linux console, but that's just too much, as it not
> > only implies a multitude of ESC sequences specific to the Linux
> > console, but also indicates that certain ioctls might work. In our own
> > code we also bind certain behaviour to TERM=linux, as indicator if we
> > are on the Linux console.
> >
> > I am not aware of any widely-supported TERM value that would be a
> > reasonable subset of all currently used terminals and does color.
> 
> I did some more research and it turns out VT220 does support colors. My 
> terminal emulator (Konsole) just doesn't seem to support it. I installed 
> xterm (which explicitly advertises support for VT220 escape codes) and got 
> colored output as expected.  I guess this means it's up to Konsole to support 
> more of VT220 if I want this to work seamlessly (or I switch terminals to 
> xterm).
> 

No vt220 does not support colour. I used to work on one and it is monochrome 
hardware.
Xterm and konsole support extensions beyond vt220 that add in the colour 
support.

Barry

> Thanks for the extra info and context.
> 
> Daan
> 
>> On Sat, 11 Jul 2020 at 20:04, Lennart Poettering  
>> wrote:
>> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote:
>> 
>> > Hi,
>> >
>> > I was playing around with mkosi's qemu support, more specifically adding
>> > the -nographic option to have the virtual machine output in my terminal
>> > instead of a separate window. After figuring out that I had to add
>> > console=ttyS0 to mkosi's kernel command line, I got the output from the vm
>> > in my terminal as expected. However, because systemd defaults to TERM=vt220
>> > for serial consoles, the output is not colorized. I searched around a bit
>> > and found that this is done for compatibility reasons. Will there ever be a
>> > point where we can switch the default to something that supports colors
>> > (like TERM=linux)?
>> 
>> TERM=linux means Linux console, but that's just too much, as it not
>> only implies a multitude of ESC sequences specific to the Linux
>> console, but also indicates that certain ioctls might work. In our own
>> code we also bind certain behaviour to TERM=linux, as indicator if we
>> are on the Linux console.
>> 
>> I am not aware of any widely-supported TERM value that would be a
>> reasonable subset of all currently used terminals and does color.
>> 
>> > I managed to get around the problem by overriding serial-getty@ttyS0 and
>> > setting Environment=TERM=linux explicitly but it's a bit of a pain and has
>> > to be added to every rootfs that wants to support colored output on its
>> > serial console.
>> 
>> Unfortunately we can't guess the right terminal, we cannot propagate
>> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
>> from a Linux console, hence the best thing we can do is stick to a
>> reasonably powerful subset that is likely going to exist everywhere,
>> and that's vt220 right now, as noone had a better suggestion so far...
>> 
>> Lennart
>> 
>> --
>> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daan De Meyer]

Nevermind that, I just forgot to remove my override file that set
TERM=linux for serial-getty@ttyS0.

Daan

On Sat, 11 Jul 2020 at 20:31, Daan De Meyer 
wrote:

> > TERM=linux means Linux console, but that's just too much, as it not
> > only implies a multitude of ESC sequences specific to the Linux
> > console, but also indicates that certain ioctls might work. In our own
> > code we also bind certain behaviour to TERM=linux, as indicator if we
> > are on the Linux console.
> >
> > I am not aware of any widely-supported TERM value that would be a
> > reasonable subset of all currently used terminals and does color.
>
> I did some more research and it turns out VT220 does support colors. My
> terminal emulator (Konsole) just doesn't seem to support it. I installed
> xterm (which explicitly advertises support for VT220 escape codes) and got
> colored output as expected.  I guess this means it's up to Konsole to
> support more of VT220 if I want this to work seamlessly (or I switch
> terminals to xterm).
>
> Thanks for the extra info and context.
>
> Daan
>
> On Sat, 11 Jul 2020 at 20:04, Lennart Poettering 
> wrote:
>
>> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote:
>>
>> > Hi,
>> >
>> > I was playing around with mkosi's qemu support, more specifically adding
>> > the -nographic option to have the virtual machine output in my terminal
>> > instead of a separate window. After figuring out that I had to add
>> > console=ttyS0 to mkosi's kernel command line, I got the output from the
>> vm
>> > in my terminal as expected. However, because systemd defaults to
>> TERM=vt220
>> > for serial consoles, the output is not colorized. I searched around a
>> bit
>> > and found that this is done for compatibility reasons. Will there ever
>> be a
>> > point where we can switch the default to something that supports colors
>> > (like TERM=linux)?
>>
>> TERM=linux means Linux console, but that's just too much, as it not
>> only implies a multitude of ESC sequences specific to the Linux
>> console, but also indicates that certain ioctls might work. In our own
>> code we also bind certain behaviour to TERM=linux, as indicator if we
>> are on the Linux console.
>>
>> I am not aware of any widely-supported TERM value that would be a
>> reasonable subset of all currently used terminals and does color.
>>
>> > I managed to get around the problem by overriding serial-getty@ttyS0
>> and
>> > setting Environment=TERM=linux explicitly but it's a bit of a pain and
>> has
>> > to be added to every rootfs that wants to support colored output on its
>> > serial console.
>>
>> Unfortunately we can't guess the right terminal, we cannot propagate
>> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
>> from a Linux console, hence the best thing we can do is stick to a
>> reasonably powerful subset that is likely going to exist everywhere,
>> and that's vt220 right now, as noone had a better suggestion so far...
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daan De Meyer]

> TERM=linux means Linux console, but that's just too much, as it not
> only implies a multitude of ESC sequences specific to the Linux
> console, but also indicates that certain ioctls might work. In our own
> code we also bind certain behaviour to TERM=linux, as indicator if we
> are on the Linux console.
>
> I am not aware of any widely-supported TERM value that would be a
> reasonable subset of all currently used terminals and does color.

I did some more research and it turns out VT220 does support colors. My
terminal emulator (Konsole) just doesn't seem to support it. I installed
xterm (which explicitly advertises support for VT220 escape codes) and got
colored output as expected.  I guess this means it's up to Konsole to
support more of VT220 if I want this to work seamlessly (or I switch
terminals to xterm).

Thanks for the extra info and context.

Daan

On Sat, 11 Jul 2020 at 20:04, Lennart Poettering 
wrote:

> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote:
>
> > Hi,
> >
> > I was playing around with mkosi's qemu support, more specifically adding
> > the -nographic option to have the virtual machine output in my terminal
> > instead of a separate window. After figuring out that I had to add
> > console=ttyS0 to mkosi's kernel command line, I got the output from the
> vm
> > in my terminal as expected. However, because systemd defaults to
> TERM=vt220
> > for serial consoles, the output is not colorized. I searched around a bit
> > and found that this is done for compatibility reasons. Will there ever
> be a
> > point where we can switch the default to something that supports colors
> > (like TERM=linux)?
>
> TERM=linux means Linux console, but that's just too much, as it not
> only implies a multitude of ESC sequences specific to the Linux
> console, but also indicates that certain ioctls might work. In our own
> code we also bind certain behaviour to TERM=linux, as indicator if we
> are on the Linux console.
>
> I am not aware of any widely-supported TERM value that would be a
> reasonable subset of all currently used terminals and does color.
>
> > I managed to get around the problem by overriding serial-getty@ttyS0 and
> > setting Environment=TERM=linux explicitly but it's a bit of a pain and
> has
> > to be added to every rootfs that wants to support colored output on its
> > serial console.
>
> Unfortunately we can't guess the right terminal, we cannot propagate
> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
> from a Linux console, hence the best thing we can do is stick to a
> reasonably powerful subset that is likely going to exist everywhere,
> and that's vt220 right now, as noone had a better suggestion so far...
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote:

> Hi,
>
> I was playing around with mkosi's qemu support, more specifically adding
> the -nographic option to have the virtual machine output in my terminal
> instead of a separate window. After figuring out that I had to add
> console=ttyS0 to mkosi's kernel command line, I got the output from the vm
> in my terminal as expected. However, because systemd defaults to TERM=vt220
> for serial consoles, the output is not colorized. I searched around a bit
> and found that this is done for compatibility reasons. Will there ever be a
> point where we can switch the default to something that supports colors
> (like TERM=linux)?

TERM=linux means Linux console, but that's just too much, as it not
only implies a multitude of ESC sequences specific to the Linux
console, but also indicates that certain ioctls might work. In our own
code we also bind certain behaviour to TERM=linux, as indicator if we
are on the Linux console.

I am not aware of any widely-supported TERM value that would be a
reasonable subset of all currently used terminals and does color.

> I managed to get around the problem by overriding serial-getty@ttyS0 and
> setting Environment=TERM=linux explicitly but it's a bit of a pain and has
> to be added to every rootfs that wants to support colored output on its
> serial console.

Unfortunately we can't guess the right terminal, we cannot propagate
TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
from a Linux console, hence the best thing we can do is stick to a
reasonably powerful subset that is likely going to exist everywhere,
and that's vt220 right now, as noone had a better suggestion so far...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel