PR:		248628
Reported by:	oleg
Reviewed by:	cem, oleg (both earlier)
Fixes:		ee97b233 ("Speed up vt(4) by keeping...")
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D32059

the foreground and background colours.  In bitblt_text functions, compare
values to this cache and don't re-draw the characters if they haven't changed.
When invalidating the display, clear this cache in order to force characters
to be redrawn; also force full redraws between suspend/resume pairs since odd
artifacts can otherwise result.

When scrolling the display (which is where most time is spent within the vt
driver) this yields a significant performance improvement if most lines are
less than the width of the terminal, since this avoids re-drawing blanks on
top of blanks.

(Note that "re-drawing" here includes writing to the VGA text mode buffer; on
virtualized systems this can be extremely slow since it triggers a glyph
being rendered onto a 640x480 screen).

On a c5.4xlarge EC2 instance (with emulated text mode VGA) this cuts the time
spent in vt(4) during the kernel boot from 1200 ms to 700ms; on my laptop
(with a 3200x1800 display) the corresponding time is reduced from 970 ms down
to 155 ms.

Reviewed by:	imp, cem
Approved by:	re (gjb)
Relnotes:	Significant speedup in vt(4) and the system boot generally.
Differential Revision:	https://reviews.freebsd.org/D16723

The VGA "text mode" buffer has a pair of bytes for each character: One
byte for the character symbol, and an "attribute" byte encoding the
foreground and background colours.  When updating the screen, we were
writing these two bytes separately.

On some virtualized systems, every write results in a glyph being redrawn
into a (graphical) virtual screen; writing these two bytes separately
results in twice as much work being done to draw characters, whereas if
we perform a single 16-bit write instead, the character only needs to be
redrawn once.

On an EC2 c5.4xlarge instance, this change cuts 1.30s from the kernel boot,
speeding it up from 8.90s to 7.60s.

MFC after:	1 week

Pointy hat to:	me
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week

x86 boot flags.

Reviewed by:	royger
Sponsored by:	The FreeBSD Foundation
Differential revision:	https://reviews.freebsd.org/D16004
MFC after:	1 week

Reviewed by:	royger
Sponsored by:	The FreeBSD Foundation
Differential revision:	https://reviews.freebsd.org/D16004

To workaround buggy firmware that sets this flag when there's actually
a VGA present.

Reported and tested by:	Yasuhiro KIMURA <yasu@utahime.org>
Sponsored by:		Citrix Systems R&D
Reviewed by:		kib
Differential revision:	https://reviews.freebsd.org/D16003

In UTF-8 locales mandoc uses a number of characters outside of the Basic
Latin group, e.g. from general punctuation or miscellaneous mathematical
symbols, and these rendered as ? in text mode.

This change adds (char, replacement, code point, description):

    ¦ | U+00A6 Broken bar
    ✓ √ U+2713 Checkmark

Sponsored by:   The FreeBSD Foundation

Before this change, the VGA palette was configured to match the shell
palette (e.g. color #1 was red). There was one glitch early in boot when
the vt(4)'s VGA palette was loaded: the loader's logo would switch from
red to blue. Likewise for the "Booting..." message switching from blue
to red. That's because the loader's logo was drawed with the default VGA
palette where a few colors are swapped compared to the shell palette
(e.g. blue <-> red).

This change configures the default VGA palette during initialization and
converts input's colors from shell to VGA palette index.

There should be no visible changes, except the loader's logo which will
keep its original color.

Reviewed by:	eadler

In UTF-8 locales mandoc uses a number of characters outside of the Basic
Latin group, e.g. from general punctuation or miscellaneous mathematical
symbols, and these rendered as ? in text mode.

This change adds (char, replacement, code point, description):

    – - U+2013 En Dash
    ⟨ < U+27E8 Mathematical Left Angle Bracket
    ⟩ > U+27E9 Mathematical Right Angle Bracket

This change addresses some common cases; there are others that still
need to be added after a more thorough review.

PR:		227409
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation

On x86 the IA-PC Boot Flags in the FADT can signal whether VGA is
available or not.

Sponsored by:		Citrix systems R&D
Reviewed by:		marcel
Differential revision:	https://reviews.freebsd.org/D14397

the same logic

MFC after:	1 month

No functional change.

We have a howmany() macro in the <sys/param.h> header that is
convenient to re-use as it makes things easier to read.

The graphic mode is noticeably slow on hypervisors, especially
on Hyper-V (1 second to each line).

Submitted by:	Dexuan Cui <decui microsoft com>
Reviewed by:	kib, sephe, royger (early loader version)
MFC after:	1 week
Sponsored by:	Microsoft OSTC
Differential Revision:	https://reviews.freebsd.org/D5739

We first map 64KB at 0xA0000 and then determine whether to work
in text or graphics mode.  When graphics mode, the mapping is
precisely what we need and everything is fine.  But text mode,
has the frame buffer relocated to 0xB8000. We didn't map that
much to safely add 0x18000 bytes to the base address.

Now we first check whether to work in text or graphics mode and
then map the frame buffer at the right address and with the
right size (0xA0000+64KB for graphics, 0xB8000+32KB for text).

PR:		202276
Tested by:	ed@

frame buffers and memory mapped UARTs.

1.  Delay calling cninit() until after pmap_bootstrap(). This makes
    sure we have PMAP initialized enough to add translations. Keep
    kdb_init() after cninit() so that we have console when we need
    to break into the debugger on boot.
2.  Unfortunately, the ATPIC code had be moved as well so as to
    avoid a spurious trap #30. The reason for which is not known
    at this time.
3.  In pmap_mapdev_attr(), when we need to map a device prior to the
    VM system being initialized, use virtual_avail as the KVA to map
    the device at. In particular, avoid using the direct map on amd64
    because we can't demote by virtue of not being able to allocate
    yet. Keep track of the translation.
    Re-use the translation after the VM has been initialized to not
    waste KVA and to satisfy the assumption in uart(4) that the handle
    returned for the low-level console is the same as later returned
    when the device is probed and attached.
4.  In pmap_unmapdev() remove the mapping from the table when called
    pre-init. Otherwise keep the mapping. During bus probe and attach
    device resources are mapped and unmapped multiple times, which
    would have us destroy the mapping used by the low-level console.
5.  In pmap_init(), set pmap_initialized to signal that we're not
    pre-init anymore. On amd64, bring the direct map in sync with the
    translations created at that time.
6.  Implement bus_space_map() and bus_space_unmap() for real: when
    the tag corresponds to memory space, call the corresponding
    pmap_mapdev() and pmap_unmapdev() functions to construct and
    actual handle.
7.  In efifb.c and vt_vga.c, remove the crutches and hacks and simply
    call pmap_mapdev_attr() or bus_space_map() as desired.

Notes:
1.  uart(4) already used bus_space_map() during low-level console
    setup but since serial ports have traditionally been I/O port
    based, the lack of a proper implementation for said function
    was not a problem. It has always supported memory mapped UARTs
    for low-level consoles by setting hw.uart.console accordingly.
2.  The use of the direct map on amd64 without setting caching
    attributes has been a bigger problem than previously thought.
    This change has the fortunate (and unexpected) side-effect of
    fixing various EFI frame buffer problems (though not all).

PR: 191564, 194952

Special thanks to:
1.  XipLink, Inc -- generously donated an Intel Bay Trail E3800
    based eval board (ADLE3800PC).
2.  The FreeBSD Foundation, in particular emaste@ -- for UEFI
    support in general and testing.
3.  Everyone who tested the proposed for PR 191564.
4.  jhb@ and kib@ for being a soundboard and applying a clue bat
    if so needed.

On one of my systems FreeBSD will fail to boot because vt_vga gets stuck
waiting for the vertical retrace if there's no monitor attached. Fix this by
adding a timeout and exiting if the vertical retrace times out.

Sponsored by: Citrix Systems R&D
Reviewed by: emaste, dumbbell
Differential Revision: https://reviews.freebsd.org/D2397

The main purpose of this feature is to be able to unload a KMS driver.

When going back from the current vt(4) backend to the previous backend,
the previous backend is reinitialized with the special VDF_DOWNGRADE
flag set. Then the current driver is terminated with the new "vd_fini"
callback.

In the case of vt_fb and vt_vga, this allows the former to pass the
vgapci device vt_fb used to vt_vga so the device can be rePOSTed.

Differential Revision:	https://reviews.freebsd.org/D687

This correctly sets the end of the memory region registered by vt_vga.

Reported by:	marius

Current VT drivers don't register the memory regions they use with the
nexus. This patch makes vt_vga and vt_efifb register the memory regions they
use.

This is needed (at least) for Xen support, since the FreeBSD kernel will try
to use the holes in the memory map to map memory from other domains and
setup it's grant table.

Sponsored by:		Citrix Systems R&D
Reported by:		sbruno
Tested by:		emaste
Reviewed by:		ray
PR:			195537
Differential Revision:	https://reviews.freebsd.org/D1291

MFC after:	3 days

This replaces the method based on Write Mode 3, which required reads
from the video memory to load the latches.

MFC after:	1 week

This allows backends to verify they do not draw outside of this area.
This fixes a bug in vt_vga where the text was happily drawn over the
right and bottom margins, when using the Gallant font.

MFC after:	1 week

MFC after:	1 week

The code was already there in all backends, we just expose it. This is
used to display the splash screen.

MFC after:	1 week

There were situations where the cursor was not erased/redrawn or its
position was marked as dirty even though it's not displayed. The code is
now more straightforward.

At the same, add a function to determine if the cursor covers a given
area. This is used by backends to know if they need to draw the cursor.

This new function should be paired with a new state in struct vt_device,
called vd_mshown, which indicates if the cursor should be displayed.
This again simplifies vd_bitblt_text_t callback's API.

MFC after:	1 week

This fixes a bug where vga_get_cp437() was called with an invalid
argument. The screen was then filled with '?' instead of the actual
character.

MFC after:	1 week

MFC after:	1 week

The previous global offset, based on the last loaded font, had no
meaning for other windows. This caused a shifted text area, often partly
out-of-screen.

MFC after:	1 week

... instead of both the buffer and the font. Again, this simplifies the
API.

MFC after:	1 week

This removes the need to specify them to each call to vd_bitblt_text_t
and, therefore, simplifies the API.

MFC after:	1 week

This fixes a bug when two windows use different fonts, but a longer-term
solution is required. The dirty area should be stored as pixels, not
character cells, because such coordinates don't have the same meaning in
all windows, when using different fonts.

MFC after:	1 week

Compared to the deprecated vd_bitbltchr_t callback, vd_bitblt_text_t
receives:
    o  the whole text buffer
    o  the dirty area
    o  the mouse cursor (map, position, colors)

This allows the backend to perform optimization on how to draw things.
The goal is to remove vd_bitbltchr_t and vd_putchar_t, once all driver
are converted (only vt_vga is included in this commit).

In vt_vga, this allows to draw the text and the cursor in one pass,
without ever reading from video memory (because it has all the context).
The main benefit is the speed improvement: no more slideshow during
boot!

Other bugs fixed in vt_vga are:
    o  left-most characters are drawn properly (the left-most pixels were
       missing with bold characters and some wide letters such as 'm')
    o  no more black square around the cursor
    o  no cursor flickering when the text is scrolling

There are still many problems to fix: the known issues are marked with
"FIXME" inside the code.

MFC after:	1 week

The goal is to clear the video memory, in case an application drew to
it. So the content shouldn't be loaded in the latches, it can't be
trusted anyway.

This improves a bit the window switch speed.

MFC after:	1 week

for mask != NULL in vd_bitbltchr, which all implementations of vd_bitbltchr()
were doing anyway.

Still one bug here: mouse left some gaps on track when moving left.

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation

This includes:
o   All directories named *ia64*
o   All files named *ia64*
o   All ia64-specific code guarded by __ia64__
o   All ia64-specific makefile logic
o   Mention of ia64 in comments and documentation

This excludes:
o   Everything under contrib/
o   Everything under crypto/
o   sys/xen/interface
o   sys/sys/elf_common.h

Discussed at: BSDcan

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation