21–30 of 62 posts
Earlier quoted context omitted.
Its not even an option on newer UEFI machines, all consoles are a framebuffer.
Let me rephrase, I don't want a huge screen with tiny fonts for my console, the default should be at most 132x48
Just curious, but does anyone know a business using OpenBSD in production other than the Pushover App?
"Optimize character rendering in 32bpp mode (John Carmack, June 2020)" Awesome
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. (-:
"Optimize character rendering in 32bpp mode (John Carmack, June 2020)" Awesome
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…
Will it support "true colors" (16M colors)[1][2]? [1] https://github.com/termstandard/colors [2] https://gist.github.com/XVilka/8346728
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 actu…
* https://itu.int/rec/T-REC-T.416
As M. Kochkov will attest, supporting 24-bit RGB (or even 32-bit ARGB) colour involves (a) recognizing and processing the new (sic!) control sequences from the 1990s, and (b) actually supporting having the display hardware in a non-palettized true colour mode (as opposed to using a 256-colour palettized mode and pretending).
The definition of a framebuffer virtual terminal is, rather, that the display hardware is in its graphics mode rather than its text mode. (This was the norm for some architectures, which didn't even have text mode display hardware. But the MDA/Hercules/CGA/EGA/VGA on the IBM PC and compatibles did.) The operating system, that is providing the virtual terminal, draws the glyphs by manipulating pixels, rather than relying upon "character generation" hardware to do it in the video output stage of the adapter.
Just curious, but does anyone know a business using OpenBSD in production other than the Pushover App?
Earlier quoted context omitted.
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 actu…
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…
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 .)
am I the only one who prefers a non-framebuffer console?
In some cases, the font is way too small. Changing the font size is confusing, because it isn't clear what size of text you will end up with.
And on some of the systems I have, the framebuffer scrolls so slow!!!!! Drives me up a wall. If it takes more than a tiny fraction of a second to display an entire screen of text, that is too slow!!!! Hate it, hate it, hate it.
Just curious, but does anyone know a business using OpenBSD in production other than the Pushover App?
Not sure if this counts, but I use it in production in yakdocs.com and yak-mu.com. I love how easy it is to maintain and I love the pf firewall. Hetzner has images for OpenBSD on their cloud service and you can use a custom image on the dedicated servers.