The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D30103
Mapping the framebuffer with WC (Write Combined) memory type can, in
practice, cause some memory transactions to be rate-limited at a
fraction of the fb write rate. WC allows one core to queue up many
globally visible write transactions, and in the process some unrelated
transactions may end up having to wait for all of the queued up PCI
writes to be flushed.
Add an hw.efifb.cache_attr tunable to allow mapping the framebuffer as
uncacheable instead. We should likely be taking a more careful approach
of checking the memory map to determine which cacheability attributes
are feasible, but the knob lets us use our historically functional
behavior while offering a convenient way to switch on a stock kernel.
The only valid values for hw.efifb.cache_attr at this time are "uc" and
"wc".
Original patch by Marc De La Gueronniere <mdelagueronniere@verisign.com>
along with previous testing.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Verisign, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D17884
This is useful to the DRM drivers to let them know if a device is
effectively used by the console.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38089
This matches the return type of pmap_mapdev/bios.
Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548
There's too many broken hardware out there that wrongly has the
ACPI_FADT_NO_VGA bit set. Ignore it unless running as a virtualized
guest, as then the expectation would be that the hypervisor does
provide correct ACPI tables.
Reviewed by: emaste, 0mp, eugen
MFC: 3 days
Sponsored by: Citrix Systems R&D
PR: 230172
Differential revision: https://reviews.freebsd.org/D34392
VGA hardware provides many different graphics and data access modes,
each with different capabilities and limitations.
VGA vt(4) graphics mode operates on blocks of pixels at a time. When a
given pixel block contains only two colours the vt_vga driver uses write
mode 3. When the block contains more than two colours it uses write
mode 0. This is done because two-colour write mode 3 is much more
efficient.
In practice write mode 3 is used most of the time, as there is often a
single foreground colour and single background colour across the entire
console. One common exception requiring the use of mode 0 is when the
mouse cursor is drawn over a background other than black, as we need
black and white for the cursor in addition to the background colour.
VGA's default 16-colour palette provides the same set of colours as the
system console, but in a different order. Previously we configured a
non-default VGA palette that had the same colours at the same indexes.
However, this caused anything drawn before the kernel started (drawn by
the loader, for instance) to change colours once the kernel configured
the new, non-default palette.
In 5e251aec86 we switched to leaving the default VGA palette in place,
translating console colour indexes to VGA colour indexes as necessary.
This translation was missed for the write mode 0 case for pixel blocks
with more than two colours.
PR: 261751
Reviewed by: adrian
MFC after: 1 week
Fixes: 5e251aec86 ("vt(4): Use default VGA palette")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34412
Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33221
Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially on modern PowerPC64 BE ones.
With the appropriate changes in SCFB, to use this ioctl to find
out the correct RGB offsets, this fixes wrong colors on Talos II
and Blackbird, when used with their built-in video cards.
Reviewed by: alfredo
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D29000
On recent OpenBMC firmware, the onboard ASMEDIA video card framebuffer
address was removed from device tree for security purposes (value is set
to zero to avoid leaking the address).
This patch works around the problem by taking framebuffer base address
from the "ranges" property of a parent node.
Reviewed by: luporl, jhibbits (on IRC)
MFC after: 2 weeks
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D30626
These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).
Sponsored by: The FreeBSD Foundation
Some framebuffer properties obtained from the device tree were not being
properly converted to host endian.
Replace OF_getprop calls by OF_getencprop where needed to fix this.
This fixes boot on PowerPC64 LE, when using ofwfb as the system console.
Reviewed by: bdragon
Sponsored by: Eldorado Research Institute (eldorado.org.br)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27475
- Implements little-endian support (powerpc64le)
- Adds 'hw.ofwfb.physaddr' kernel parameter so user can manually
provide correct address if it's not detected correctly
- Adds 'hw.ofwfb.argb32_pixel' so user can set it manually if
colors are inverted due to incorrect pixel format (default = 1)
- Automatically selects RGBA32 pixel format if NVidia graphic adapter
is detected (sets hw.ofwfb.argb32_pixel=0)
Machines equipped with NVidia graphic adapters tend to use RGBA32
pixel format. By default ARGB32 pixel format is used, proved to work
on machines equipped with ATI graphic adapter and the onboard adapter
used on Talos II and Blackbird machines from Raptor Computing Systems.
Original patch developed by bdragon
Reviewed by: bdragon, luporl
MFC after: 3 days
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28604
Implement vt_vbefb to support Vesa Bios Extensions (VBE) framebuffer with VT.
vt_vbefb is built based on vt_efifb and is assuming similar data for
initialization, use MODINFOMD_VBE_FB to identify the structure vbe_fb
in kernel metadata.
struct vbe_fb, is populated by boot loader, and is passed to kernel via
metadata payload.
Differential Revision: https://reviews.freebsd.org/D27373
vt_generate_cons_palette() does take max values of RGB component colours, not
mask. Also we need to set info->fb_cmsize, or vt_fb_init() will re-initialize
the info->fb_cmap.
vm_ooffset_t is now unsigned. Remove some tests for negative values,
or make other adjustments accordingly.
Reported by: Coverity
Reviewed by: kib markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D26214
The reporter is developing a frame buffer driver for hardware using
3 bytes per pixel, but a stride that's a multiple of 256. Previously
this resulted in writing beyond the end of each stride. On the last
row this attempted to write past the end of the frame buffer, triggering
the assertion in vt_fb_mem_wr1().
PR: 243533
MFC after: 2 weeks
Submitted by: Thomas Skibo
This change enables the use of OpenFirmware Console (ofwcons), even when VGA is
available, allowing early kernel messages to be seen, that is important in case
of crashes before VGA console initialization.
This is specially useful in virtualized environments, where the user/developer
doesn't have full control of the virtualization engine (e.g. OpenStack).
The old behavior is preserved by default and, in order to use ofwcons, a few
tunables that have been introduced need to be set:
- hw.ofwfb.disable=1 - disable OFW FrameBuffer device
- machdep.ofw.mtx_spin=1 - change PPC OFW mutex to SPIN type, to match kernel
console's mutex type
- debug.quiesce_ofw=0 - don't call OFW quiesce, needed to keep ofwcons I/O
working
More details can be found at differential revision D20640.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20640
The TUNABLE_INT_FETCH is macro around getenv_int() and we will get
return value 0 or 1 for failure or success, we can use it to decide
which background color to use.
Using the latest NVIDIA driver, upon resuming from suspend with X
running the display remained blank. Additionally OpenGL applications
that were running triggered a number of error messages from the NVIDIA
driver.
This occurred because the vt efifb back-end did not signal the X server
to release the display before suspending (or to re-acquire it after
resuming). The NVIDIA driver includes code for smoothly shutting down
and re-initializing the GPU, which was not getting called.
Since the NVIDIA driver doesn't currently support framebuffer devices
and vt is forced to fall back to the efifb back-end, add vd_suspend and
vd_resume members to connect the suspend/resume path. This ensures the
X server is properly able to re-initialize the display.
PR: 237050
Submitted by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed by: markj
MFC after: 2 weeks
Event: Waterloo Hackathon 2019
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
/chosen/stdout-path is a string, not ihandle. Treat it as such.
With this, ofwfb now starts correctly on a POWER9 system when launched from
the local console (not serial).
The FDT implementation of OF_instance_to_package() backend checks the
cross-reference to get the node. On failure, this returns the input handle
unchanged. In the case of ofwfb attachment, if /chosen/stdout property does not
exist, sc->sc_handle is either garbage or 0, which then gets propagated to node.
This will prevent "screen" from being used, resulting in not properly attaching.
Correct this by matching the code in ofwfb_probe().
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
overscan and synthesize it from the display depth and screen width.
This may not be right, but it sometimes right and is better than
returning CN_DEAD.
MMU is disabled.
This expands some earlier logic and avoids a number of potential problems:
1. The CPU may not be able to access the framebuffer in real mode (real
mode does not necessarily encompass all available memory, especially
under a hypervisor).
2. Real mode accesses generally assume cacheability, so it might not
even have worked.
3. The difference in cacheability between real mode and later (and
potentially earlier) points in the boot with the MMU on may cause
ERAT parity problems, resulting in a machine check.
This fixes real-mode (usefdt=1) early boot on the G5 iMac, which was
previously broken as a result of issue #3. Late boot will require some
other fixups.
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
accomplishes a few things:
- Makes NULL an invalid address in the kernel, which is useful for catching
bugs.
- Lays groundwork for radix-tree translation on POWER9, which requires the
direct map be at high memory.
- Similarly lays groundwork for a direct map on 64-bit Book-E.
The new base address is chosen as the base of the fourth radix quadrant
(the minimum kernel address in this translation mode) and because all
supported CPUs ignore at least the first two bits of addresses in real
mode, allowing direct-map addresses to be used in real-mode handlers.
This is required by Linux and is part of the architecture standard
starting in POWER ISA 3, so can be relied upon.
Reviewed by: jhibbits, Breno Leitao
Differential Revision: D14499
Summary:
As in /dev/fb, allow the framebuffer driver to override the default memattr for
mmap(2). This is analogous to the change in 306555.
Reviewed By: ray
Differential Revision: https://reviews.freebsd.org/D13331
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
