Calculate font size from 16 density independent pixels (dp) by using:
size = 16 * ppi/160 * display_factor
We are specifying font size 16dp, and assuming 1dp = 160ppi.
Also apply scaling factor 2 (display_factor).
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28849
If we start with console set to comconsole, the local
console (vidconsole, efi) is never initialized and attempt to
use the data can render the loader hung.
Reported by: Kamigishi Rei
MFC after: 3 days
We do select font based on desired terminal size, we do query
UEFI terminal size with conout->QueryMode(), but by mistake, the fallback
values are used.
Pass gfx_state to efi_find_framebuffer(), so we can pick between
GOP and UGA in efi_find_framebuffer(), also we can then
set up struct gen_fb in gfx_state from efifb and isolate efi fb data
processing into framebuffer.c.
This change does allow us to clean up efi_cons_init() and reduce
BS->LocateProtocol() calls.
A little downside is that we now need to translate gen_fb back to
efifb in bootinfo.c (for passing to kernel), and we need to add few
-I options to CFLAGS.
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.
Export variables:
screen.height
screen.width
screen.depth
Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.
Probably something else I forgot...
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
The efi console init is avoided since conin setup was moved to probe.
In case the console is re-initialized, we need to pick up colors
from environment.
From UEFI specification 2.8, page 434:
"It should also be noted that certain input devices may not be able to produce
shift or toggle state information, and in those cases the high order bit in
the respective Toggle and Shift state fields should not be active."
But we still need to check for ScanCode and UnicodeChar.
PR: 242660
Reported by: Trond Endrestol
MFC after: 1 week
RB_MULTIPLE without RB_SERIAL set is valid, and means 'Video first, then serial'
to the kernel (so kernel messages go to both, but /etc/rc uses video console
(this should be fixed, btw, but another day)). Check for RB_MULTIPLE as well as
RB_SERIAL where we want to to serial things. This means we'll use the old code
for emulation in these situations, which is likely best since we're outputing to
both and the old code is ligher weight allowing both to keep up w/o weird
scrolling things.
In case of efi console having serial backend (video + serial or only serial),
we need to stick with old emulator till we can draw console.
Eventually we would need to get console terminal emulator to be removed
from serial console because the serial link already has the terminal.
However, we need to implement comconsole on all efi platforms first, then
we need the ability to draw console, so we do not have to use SimpleTextOutput
protocol (which will write both on video and serial in case of multiplexed
ComOut).
Differential Revision: https://reviews.freebsd.org/D22161
Since local UEFI console is implemented on top of framebuffer,
we need to avoid redrawing the whole screen ourselves, but let
Simple Text Mode to do the scroll for us.
Add settable variables to control teken default color attributes.
The supported colors are 0-7 or basic color names:
black, red, green, brown, blue, magenta, cyan, white.
The current implementation does add some duplication which will be addressed
later.
Replace mini cons25 emulator with teken, this does enable us proper console
terminal for loader and will make it possible to implement different
back end callbacks to draw to screen.
At this time we still only "draw" in text mode.
This fix is ported from illumos (issue #9970), the analysis and initial
implementation was done by John Levon.
See also: https://www.illumos.org/issues/9970
Currently, efi_cons_getchar() will wait for a key. While this seems to make
sense, the implementation of getchar() in common/console.c will loop across
getchar() for all consoles without doing ischar() first.
This means that if we've configured multiple consoles, we can't input into
the serial, as getchar() will be sat waiting for input only from efi_console.c
This patch does implement a bit more generic key buffer to support
translation of input keys, and we use generic efi_readkey() to reduce
duplication from calls from getchar() and poll().
up serial output. Setting the cursor position after every character is
inefficient, and causes all lines to be over-printed in the serial
console for the boot loader. Allow the terminal to do the emulation.
This isn't completely perfect when the size of the terminal attached
to the serial port isn't the same as 80x25 to match the viedoe console
(or whatever the video console is). While imperfect still, these
changes make it much better.
This makes the serial port useful with UEFI.
Differential Revision: https://reviews.freebsd.org/D16309
