
Modernizing the OpenBSD Console - zdw
https://www.cambus.net/modernizing-the-openbsd-console/
======
saagarjha
Interestingly, some of the newer commits seem to have come from John Carmack.

While it's not quite related to consoles, I've noticed that the non-GUI
interface to a lot of operating systems often don't get a lot of love. Linux
has had a fairly nice boot scroll, but I think part of that is because it's
become an icon and as such is part of the public face of the OS; but on macOS
for example it's an tiny awful experience because the text doesn't scale to 2x
(you'd think _Apple_ would be the first one to fix this…) and the output isn't
well formatted at all–it's just the various subsystems spewing text as they
start up. And a lot of modern systems use kind of old fonts that in many cases
seemed to be picked as an afterthought…

~~~
abrookewood
If I recall correctly, there was an article on HN not so long ago about
Carmack discovering BSD. Edit: found it -
[https://news.ycombinator.com/item?id=23224584](https://news.ycombinator.com/item?id=23224584)

~~~
hnlmorg
s/discovering/committing to/

Carmack has been aware of and actively involved in UNIX systems for a long
time now. This isn't a recent discovery. However it has been recently noticed
that he's committing to OpenBSD.

~~~
notaplumber
Contributing to OpenBSD, not committing. He is not a committer.. yet.

~~~
hnlmorg
Apologies, I hadn't realised there were a distinction. What's the difference?

~~~
kasabali
I guess it's about having a direct commit access to their CVS tree.

~~~
notaplumber
Precisely. OpenBSD developers have committed John's diffs.

------
rbanffy
What really disappoints me is that, with all those pixels, and _bits per
pixel_ we now have, it still can't have proper bold, italic, underline,
overline, Tek graphics, sixels, and smooth scrolling like any ancient terminal
made by any well regarded hardware company.

~~~
HugoDaniel
indeed :O

here are the VT100 ansi escape codes:
[https://espterm.github.io/docs/VT100%20escape%20codes.html](https://espterm.github.io/docs/VT100%20escape%20codes.html)

Bold, Underline, Double height, double width, etc... are all there. VT100,
from 1978.

~~~
msla
ncurses gives you all of that in a much easier-to-use fashion.

~~~
rbanffy
True, but not really relevant in this context. The fact is that graphical
consoles could support all that because, in reality, there was a time they
actually did - they were just independent embedded computers connected to the
host via a serial port.

In my dreams, when switching to Tek mode, the framebuffer would have a dark
green background, the lines would have a brighter green, and drawing would
push the HDR for the brightest green it'd be able to do (because to store a
vector in a Tektronix DVST, you flash it with a high energy beam). Erasing the
screen would flash it light green and there would be no scrolling.

------
unixhero
"Optimize character rendering in 32bpp mode (John Carmack, June 2020)"

Awesome

~~~
JdeBP
It's the sort of optimization that one can read about in games and DirectX
programming books.

A better optimization comes with the realization, as MacOS people had many
years ago, that copying from system memory to video memory is slow. So one
instead pre-loads the glyphs into off-screen video memory, possibly on-demand,
and then uses the display hardware to blit them into the on-screen part.

Of course, this requires that code know about blitter hardware, which does not
necessarily exist. If one is doing an in-kernel terminal emulator, such as
wscons in OpenBSD here, then one can rely upon the fact that the EFI Graphics
Output Protocol provides a Blt() function that is supposed to abstract away
the hardware. Indeed, EFI GOP can in theory not provide direct framebuffer
access in the first place and require that everything be blitted
(PixelBltOnly).

We who write application-mode terminal emulators are not so fortunate. (-:

~~~
mjg59
GOP functions aren't available after ExitBootServices() has been called, so
the kernel doesn't get to take advantage of Blit() - the assumption is that
the kernel will have a native driver for the hardware. Additionally, you can't
really use off-screen graphics RAM in the EFI environment because GOP doesn't
tell you how much video RAM is actually available, only the size of the
framebuffer. You can guess which PCI device is associated with the framebuffer
and look at the size of the BAR, but you have no way of knowing which
addresses the EFI driver is using for its own purposes. Apple have enough
control over their platform that they could possibly make this work, but it's
tough when you're dealing with a vendor-provided driver on an add-in card.

~~~
JdeBP
Hah! I've been doing too much load-time stuff, obviously. (-:

But if one is looking at PCI device IDs, then one is _already at_ the level of
the code having detailed knowledge of the specific hardware (even if only via
some "miniport"-like system) and the point stands.

~~~
mjg59
Oh, you can look at the device that the GOP instance is bound to and get the
PCI device from there. At that point you just walk the BARs looking for one
that's mapped in a region that covers the framebuffer address that GOP gives
you. This doesn't require you to know anything about the device in question,
and most of the time you'd probably get lucky by throwing glyphs in space that
exists outside the framebuffer and blitting them onto the screen - up until
you find a driver that implements blt() by using the 3D engine and mapping
some buffer objects on top of the space you're trying to use.

~~~
JdeBP
The code will still have to know about blitter hardware, as I said.

Any design that depends from "you'd probably get lucky" is not a wise one. (-:

------
xvilka
Will it support "true colors" (16M colors)[1][2]?

[1]
[https://github.com/termstandard/colors](https://github.com/termstandard/colors)

[2]
[https://gist.github.com/XVilka/8346728](https://gist.github.com/XVilka/8346728)

~~~
watersb
The article uses 32 bits per pixel to illustrate the growth in performance
requirements:

> In framebuffer however, to fill a 4K UHD-1 (3840x2160) screen in 32bpp mode
> we need to send 3840 * 2160 * 4 bytes of data, which is 33177600 bytes
> (approximately 33 MB).

but I don't know if that is in fact the definition a "framebuffer console"
versus a terminal that uses character addressing.

That's a different issue that actually supporting 32-bit ANSI codes, but I
think it's an indication of the scope of a an effort to update the console
implementation.

~~~
asveikau
Some of the code linked in the article seems to emulate the VGA style text
console (1 value for char value, 1 value for color and attributes) and render
it onto a 32bit framebuffer.

The diffs that are attributed to Carmack seem to deal with this.
scr->rs_bs[off].uc and scr->rs_bs[off].attr appear to represent the gylph and
attributes/color respectively.

So I would expect that would severely limit the amount of colors available to
the input buffer. OTOH I just found the declaration in the code and the
attributes are 32 bits wide which is more than the 8 that VGA provides:

    
    
        struct wsdisplay_charcell {
           u_int       uc;
           uint32_t    attr;
        };
    

Note I would expect the 32 bits of attr to be divided between fg and bg color,
and it seems like they carved out bits for things like underline.

Edit: after reading some more it seems like the color values range from 0-7.

~~~
JdeBP
32 bits isn't really enough. One uses 24 bits for RGB, and the remaining 8
bits aren't really enough for the remaining graphics renditions that a modern
terminal emulator should support.

Factor in things like the KiTTY underlining system, invisible, the little-
recognized new (sic!) ECMA-48:1991 graphic renditions (encircled, framed, and
overlined), and strikethrough; and one actually needs 13 to 14 bits (depending
from how far one takes the KiTTY underlining system).

Moreover: No-one doing this style of terminal emulator really does Unicode
properly. To do so actually involves having a string of one or more code
points per cell, not simply exactly one. Some of the terminal emulators based
upon external GUIs (e.g. X11) do do that, or approach it. (Although at the
same time they take a giant leap backwards from video terminal semantics to
paper terminal semantics, so it is a matter of swings and roundabouts. See
[https://unix.stackexchange.com/a/593613/5132](https://unix.stackexchange.com/a/593613/5132)
.)

~~~
asveikau
> 32 bits isn't really enough. One uses 24 bits for RGB,

Yes, and as I mentioned you need to divide between FG and BG colors.

All a little moot because it seems to me like the code uses 3 bits for color.

> No-one doing this style of terminal emulator really does Unicode properly

Indeed, both multi-char and multi-codepoint glyphs. I also think the whole
"matrix of glyphs" thing breaks down pretty severely when you want BiDi
support for instance. The article mentions someone working on UTF-8 support. I
wonder what that looks like.

------
TimSchumann
Just curious, but does anyone know a business using OpenBSD in production
other than the Pushover App?

~~~
LeoPanthera
Virtually everyone uses _bits_ of OpenBSD. Android uses a lot of its C
standard library, LLVM uses its regular expression library, and Windows 10
uses OpenSSH with LibreSSL.

Armorlogic, Calyptix Security, GeNUA, RTMX, and .vantronix make network
appliances based on the complete OS.

~~~
smabie
Don't forget tmux, cwm, openbgpd, and openntp. The OpenBSD guys consistently
make very high quality tools.

~~~
aaron_m04
cwm is a diamond in the rough for sure. Doesn't look like much but it's so
easy to configure and use.

~~~
smabie
I absolutely love cwm. Best floating window manager, hands down.

------
Aloha
am I the only one who prefers a non-framebuffer console?

~~~
throwaway2048
Its not even an option on newer UEFI machines, all consoles are a framebuffer.

~~~
Aloha
Let me rephrase, I don't want a huge screen with tiny fonts for my console,
the default should be at most 132x48

~~~
rvense
Isn't that exactly what this patch addresses? Updating the framebuffer console
so it's not horrible on modern framebuffers.

~~~
Aloha
the OS/Distro should chose sensible options out of the box, they usually do
not.

------
Koshkin
Hopefully not too off-topic, I have a question: shouldn't we stop using
terminal emulators already (i.e. why do we still require emulating the
terminal _hardware_ designed in 1970)? Wouldn't a text editor-like user
interface be more sensible? (Perhaps, something similar to emacs' M-x shell
but more universally adopted.)

------
hideevidence
I want to note kmscon, it's really distraction free terminal. Best of all it
easily supports unicode points with no added user effort.

