Hi Andrew, I tested VT_UTF8 on the macOs Terminal software and I can confirm that VT_UTF8 renders nicely. See the attached screenshot. Thanks, Nate On 3/17/21, 9:02 AM, "Andrew Fish" wrote: If we are mentioning terminal types the default terminal type on a Mac is xterm-256color. So that is going to be the default when people run OVMF on a Mac. So it would be nice if we can add that. I can help out with anything xterm-256color related. Thanks, Andrew Fish > On Mar 16, 2021, at 8:23 AM, Laszlo Ersek wrote: > > 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. >> >> https://github.com/tianocore/tianocore.github.io/wiki/Tasks-Terminal-driver-improvements > > ( > > 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 latin2). > > ) > > * 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.) > > 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: > > http://mid.mail-archive.com/555458DB.3090602@redhat.com > http://mid.mail-archive.com/CAFECyb_E+bGZt5xv7QhRqyD0jX=AzoEMw7VW_tjZr+E=sQf8ww@mail.gmail.com > > (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* supposed > to use DEC Special Graphics, I can't tell. > > 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. > > Thanks! > Laszlo > > > > > >