Date: Mon, 2 Mar 2020 10:47:41 +0200 From: Toomas Soome <tsoome@me.com> To: FreeBSD Current <current@FreeBSD.ORG> Subject: about loader & console Message-ID: <AC468F1F-6134-4ED4-BFEB-A83E3583C62A@me.com>
next in thread | raw e-mail | index | archive | help
Hi! I have been busy with other bits for some time, but now back to poking = some bits. What we have now (on current): x86:=20 vidconsole on BIOS systems. Text mode, the screen is managed by teken = terminal emulator, we =E2=80=9Cdraw=E2=80=9D on vga text buffer.=20 comconsole: serial port driver shared by BIOS and UEFI mode. efi: Text mode, console =E2=80=9Cdevice=E2=80=9D which can have gfx = display, serial port or both connected as back end device, connection is = done by the firmware. We write by using UEFI Simple Text Output = Protocol. See also ConOut UEFI variable. To manage the screen, the efi console also defaults to use teken = terminal emulator, however, if the serial port is multiplexed to ConOut, = we can not have =E2=80=9Cour=E2=80=9D terminal emulator to draw the = screen, as that would distort the serial console. And worse, at least = some UEFI firmware implementations do not pass ESC code via simple text = output protocol, causing the console being filled by broken CSI = sequences. arm: efi console is the same state as in x86, no serial driver to = provide comconsole, the serial console is only available via redirection = from firmware. I actually do have basic comconsole implementation via UEFI Serial IO = protocol, but unfortunately, the UEFI API does not provide good way to = identify serial ports, we only do get array of handles of serial ports. = The SIO handle is opaque. What we want to get:=20 We would like to have framebuffer console (at least on efi), where we do = =E2=80=9Cdraw=E2=80=9D the glyphs and do not use simple text output = protocol for console output.=20 Why: this will allow us to provide more consistent screen output, draw = images and we would not depend on simple text output any more. UEFI gfx console is already built on framebuffer - on physical systems = we do get FB address, size and few other attributes, and after passing = this all to kernel, the kernel will draw the conole, as Simple Text = Output Protocol is not available once we start the kernel. To get this done, we need console font. To be able to output text, I do = plan to build into loader binary the limited set (ascii + box drawing) = 8x16 font, and once we have gained access to the disk, we will load best = matching font for the current resolution. This makes first problem - we = have font files in usr/share/vt/fonts, but there are too many options = where the /usr might be, so we would need to copy some of those fonts to = /boot tree. I=E2=80=99d use terminus fonts there for consistency (glyph = range) for various glyph sizes. And the kernel default built in font is = 8x16 terminus. With ability to draw our glyphs, we can build console device list in = console variable, just as it is currently done with x86 BIOS version. If = we should still use the console name =E2=80=9Cefi=E2=80=9D for FB = console or leave efi for pure Simple Text Output based console, is = something we would need to decide. Once we can draw the FB console on UEFI, it is not too hard to add the = implementation for BIOS VBE interface. To sum it all up: 0. my assumption is/was that we do not change the name of the console = driver, to keep the expected values people are used with. However, it is = quite easy to introduce new console types, if needed. 1. We need to provide serial driver on all platforms. 2. Provide option to switch between =E2=80=9Ctext=E2=80=9D and gfx mode. = In some systems (BIOS VGA) the gfx performance may be very low and text = mode might be preferred.=20 3. The screen updates are to be implemented via teken callback mechanism = (as it is also done in kernel for that matter). 4. The support to display images is using pnglite (and therefore png = format). Interpreters need updates to support the feature. I actually do have the core implementation for UEFI already, but = polishing it up will still get some time. Actually I am cheating there = quite a bit because I have done all this work already once and now I am = porting it to different terminal emulator. I hope this writeup does give some light about what is happening in this = area. thanks, toomas=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC468F1F-6134-4ED4-BFEB-A83E3583C62A>