Re: Google Summer of Code Interested Student

Nate DeSimone

Hi Laszlo,

-----Original Message-----
From: <> On Behalf Of
Laszlo Ersek
Sent: Tuesday, March 16, 2021 8:24 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@...>
Cc:; cadenkline9@...; edk2-devel-groups-io
<>; Ard Biesheuvel (TianoCore)
<ardb+tianocore@...>; Leif Lindholm (Nuvia address)
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

Hi Nate,

(adding Leif and Ard)

On 03/13/21 03:52, Desimone, Nathaniel L wrote:
I've created a new wiki page for this task with all the information I
have gathered thus far. I've done some more experimentation and found
that there are several newer terminal emulators that don't support DEC
Special Graphics so I've reduced the number of modes where DEC Special
Graphics should be preferred. Laszlo, if you could take a look at the
terminal type matrix I created that would be very helpful.

My background:

I settled on plain (non-UTF-8) xterm around 1998, and have been using it
ever since. Whenever something was off, I always tried to hammer the
application into conformance with my particular xterm setup, rather than the
other way around. I also have some quirky terminal settings -- for me,
"backspace" generates ^H / keycode 22 (stty sets erase to ^H), "delete"
generates keycode 119, and there's no "rubout". I still don't use UTF-8 (I use


* Regarding ArmVirtPkg, I stick with the default TTY_TERMINAL=FALSE
setting (which means VT-100). Using that setting, I see the following
kind of "ASCII approximation" for box drawing:

| Boot Manager |

I'm really happy with this, as I don't care much for nice-looking
boxes; instead I prefer portability.

(NB: this seems to disagree with your "Current Behavior (Which is
wrong)" line for VT100, as it suggests CP437. That's not what I'm
seeing with VT100.)
I went back and looked at this is more detail, and I missed the following critical detail:

if (TerminalDevice->TerminalType != TerminalTypePcAnsi) {
GraphicChar = AsciiChar;

Yes you are totally right! I've adjusted the table to reflect this behavior.

TTY_TERMINAL=TRUE would mainly affect backspace / delete I think -- as
far as I recall, that's why I asked Roy not to make TTY_TERMINAL=TRUE
the default, in 2015:

(I'd like to CC Roy, but I can't tell if he's now working for Linaro,
Cavium, HPE, Marvell, or another company.)

* Regarding OvmfPkg, currently PC_ANSI is hard-coded, and for me it
looks like this:

ł Boot Manager ł


Obviously I'd much prefer if I got the simple ASCII approximation here
as well.

* Whether VT100 and/or PC_ANSI and/or TTY_TERM are *officially*
to use DEC Special Graphics, I can't tell.
The UEFI spec doesn't read on this at all, even though it describes VT100 and VT100+ as separate modes... it doesn't say how they differ. I agree with you that it seems reasonable for VT100 to keep character output to strict ASCII only... that way the "+" in VT100+ actually means something. I've updated the wiki accordingly.

I'd advocate for the default to be switched to VT_UTF8. I really don't think you will run into many terminal emulators that don't implement UTF-8 anymore, XTerm included. Those who want pure ASCII output can switch to VT100.

I know what my preferences are:

- the current BackSpace and Delete mappings (which work fine for me
with both VT100 and PC_ANSI, but *not* with TTY_TERM),

- and the most primitive ASCII mapping (no special graphics, no UTF-8
sequences, etc). I really like a super dumb terminal, where taking
simple "ASCII screenshots" (and pasting them into plaintext emails!)
is *trivial*.

... Looking at your "Expected Behavior" table, there is only one line
left with "poor man's ASCII" -- namely, TTY_TERM. Unfortunately,
TTY_TERM breaks my BackSpace / Delete settings :(

* In summary, I'd prefer if (a) VT100 stayed as-is (using "poor man's
ASCII", as seen in ArmVirtPkg), and (b) if OVMF used *that* VT100,
rather than PC_ANSI, by default.


Join { to automatically receive all group messages.