"Terminus BSD Console" is a derivative of Terminus that is provided
by Mr. Dimitar Zhekov under the 2-clause BSD license for use by the
FreeBSD vt(4) console and other BSDs.
PR: 227409
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
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
opt_compat.h is mentioned in nearly 180 files. In-progress network
driver compabibility improvements may add over 100 more so this is
closer to "just about everywhere" than "only some files" per the
guidance in sys/conf/options.
Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset of
sys/compat/linux/*.c. A fake _COMPAT_LINUX option ensure opt_compat.h
is created on all architectures.
Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control the
set of compiled files.
Reviewed by: kib, cem, jhb, jtl
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14941
Invalid font data passed to PIO_VFONT can result in an integer overflow
in glyphsize. Characters may then be drawn on the console using glyph
map entries that point beyond the end of allocated glyph memory,
resulting in a kernel memory disclosure.
Submitted by: emaste
Reported by: Dr. Silvio Cesare of InfoSect
Security: CVE-2018-6917
Security: FreeBSD-SA-18:04.vt
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
Trying to grab locks during cngrab() when entering the debugger is
deadlock prone as all other CPUs are already halted (and thus unable
to release locks) when cngrab() is invoked. One could instead use
try-locks. However, the case that the try-lock fails still has to
be handled. In addition, if the try-lock works it doesn't provide
any greater ordering guarantees than is already provided by entering
and exiting DDB. It is simpler to define a simpler path for the
case that the try-lock would fail and always use that when entering
DDB. Messing with timers, etc. when entering DDB is dubious even if
the try-lock succeeds.
This patch attempts to use the smallest possible set of operations to
grab the vt(4) console when entering DDB without using any locks.
Reviewed by: emaste
Tested by: Matthew Macy
MFC after: 1 week
During review iterations function signature has changed in definition
but not in actual call. Fix call to match the definition.
Reported by: Herbert J. Skuhra
Pointyhat to: gonzo
MFC after: 2 weeks
Introduce new set of loader tunables kern.vt.color.N.rgb, where N is a
number from 0 to 15. The value is either comma-separated list decimal
numbers ranging from 0 to 255 that represent values of red, green, and
blue components respectively (i.e. "128,128,128") or 6-digit hex triplet
commonly used to represent colors in HTML or xterm settings (i.e. #808080)
Each tunable overrides one of the 16 hardcoded palette codes and can be set
in loader.conf(5)
Reviewed by: bcr(docs), jilles, manu, ray
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13645
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.
- Do not report T-axis wheel events as button presses
- Reverse T-axis to match Linux
- Remove wrong comment. T-axis buttons state should be checked by level not
by edge to allow continuous wheel tilt reporting
Reviewed by: gonzo
Approved by: gonzo (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D12676
was aliased to a vt sequence, causing and fixing various bugs.
For syscons, this restores support for arg 2 which sets blinking block
too forcefully, and restores bugs for arg 0 and 1. Arg 2 is used for
vs in the cons25 entry in termcap, but I've never noticed an application
that uses this. The bugs involve replacing local settings by global
ones and need better handling of defaults to fix.
For vt, this requires moving the aliasing code from teken to vt where
it belongs. This sequences is very important for cons25 compatibility
in vt since it is used by the cons25 termcap entries for ve, vi and
vs. vt can't properly support vs for either cons25 or xterm since it
doesn't support blinking. For xterm, the termcap entry for vs asks
for something different using 12;25h instead of 25h.
Rename C25CURS for this to C25LCT and change its description to be closer
to echoing the old comment about it. CURS is too generic.
Fix missing syscons escape sequence for setting the global cursor shape
(and type). Only support this in syscons since vt can't emulate anything
in it.
during bootup. Debugging information shows that softclock_call_cc() is
trying to execute the vt_consdev.vd_timer callout, and the callout
structure contains a NULL c_func.
This appears to be due to a race between vt_upgrade() running
callout_reset() and vt_resume_flush_timer() calling callout_schedule().
Fix the race by ensuring that vd_timer_armed is always set before
attempting to (re)schedule the callout.
Discussed with: emaste
MFC after: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D9828
for vt. Restore syscons' rendering of background (bg) brightness as
foreground (fg) blinking and vice versa, and add rendering of blinking
as background brightness to vt.
Bright/saturated is conflated with light/white in the implementation
and in this description.
Bright colors were broken in all cases, but appeared to work in the
only case shown by "vidcontrol show". A boldness hack was applied
only in 1 layering-violation place (for some syscons sequences) where
it made some cases seem to work but was undone by clearing bold using
ANSI sequences, and more seriously was not undone when setting
ANSI/xterm dark colors so left them bright. Move this hack to drivers.
The boldness hack is only for fg brightness. Restore/add a similar hack
for bg brightness rendered as fg blinking and vice versa. This works
even better for vt, since vt changes the default text mode to give the
more useful bg brightness instead of fg blinking.
The brightness bit in colors was unnecessarily removed by the boldness
hack. In other cases, it was lost later by teken_256to8(). Use
teken_256to16() to not lose it. teken_256to8() was intended to be
used for bg colors to allow finer or bg-specific control for the more
difficult reduction to 8; however, since 16 bg colors actually work
on VGA except in syscons text mode and the conversion isn't subtle
enough to significantly in that mode, teken_256to8() is not used now.
There are still bugs, especially in vidcontrol, if bright/blinking
background colors are set.
Restore XOR logic for bold/bright fg in syscons (don't change OR
logic for vt). Remove broken ifdef on FG_UNDERLINE and its wrong
or missing bit and restore the correct hard-coded bit. FG_UNDERLINE
is only for mono mode which is not really supported.
Restore XOR logic for blinking/bright bg in syscons (in vt, add
OR logic and render as bright bg). Remove related broken ifdef
on BG_BLINKING and its missing bit and restore the correct
hard-coded bit. The same bit means blinking or bright bg depending
on the mode, and we want to ignore the difference everywhere.
Simplify conversions of attributes in syscons. Don't pretend to
support bold fonts. Don't support unusual encodings of brightness.
It is as good as possible to map 16 VGA colors to 16 xterm-16
colors. E.g., VGA brown -> xterm-16 Olive will be converted back
to VGA brown, so we don't need to convert to xterm-256 Brown. Teken
cons25 compatibility code already does the same, and duplicates some
small tables. This is mostly for the sc -> te direction. The other
direction uses teken_256to16() which is too generic.
The {powerpc,powerpc64,sparc64} LINT kernel builds fail with this error:
sys/dev/vt/vt_buf.c:198: warning: 'vtbuf_htw' defined but not used
Move vtbuf_htw() inside the '#if SC_NO_CUTPASTE' block where it belongs, and
put it in the proper order.
This fixes the immedate issue w/ vt(4), but all three then fail on different
issues.
Reviewed by: emaste
For horizontal (T-axis) wheel reporting which is not supported by
sysmouse protocol kern.evdev.sysmouse_t_axis sysctl is introduced.
It can take following values:
0 - no T-axis events (default)
1 - T-axis events are originated in ums(4) driver.
2 - T-axis events are originated in psm(4) driver.
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8597
On the first switch we previously released the newly allocated keyboard
instead of the old one. Keyboard state was very confused afterwards for
further keyboard switches.
Submitted by: bde
Note that keyboards are stored in an array and are not freed (just
"unregistered" by clearing some fields) so a race would be limited to
obtaining stale information about an unregistered keyboard.
Reported by: CTurt
MFC after: 3 days
And rename "DEFAULT" constants to the more accurate "MAX."
PR: 210382
Submitted by: Felix <felixphew0 at gmail.com>
Reviewed by: wblock, cem
Tested by: Dave Cottlehuber <dch at skunkwerks.at>
rounddown2 tends to produce longer lines than the original code
and when the code has a high indentation level it was not really
advantageous to do the replacement.
This tries to strike a balance between readability using the macros
and flexibility of having the expressions, so not everything is
converted.
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
will allow for code that uses the old fdt_get_range and fdt_regsize
functions to find a range, map it, access, then unmap to replace this, up
to and including the map, with a call to OF_decode_addr.
As this function should only be used in the early boot code the unmap is
mostly do document we no longer need the mapping as it's a no-op, at least
on arm.
Reviewed by: jhibbits
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5258
size as defined by VT_FB_DEFAULT_WIDTH and VT_FB_DEFAULT_HEIGHT
(at this time 2048x1200). The default is really a max. We cap
the height and width to those defaults and position the screen
in the center of the frame buffer.
Ideally we use a bigger font to utility the entire real estate
that is the frame buffer, but that's seen as an improvement over
making it work first.
PR: 193745
horizonal resolution (width). In those cases fb_bpp ended up
completely wrong -- as in 6 bytes per pixel or something like
that. Since we already have a way to calculate fb_depth given
the masks and fb_bpp is effectively the same as fb_depth, all
we need to do is make sure fb_bpp is rounded to the next
multiple of the number of bits in a byte -- we assume we can
divide by the number of bits in a byte throughout vt(4).
While here:
- simplify how we calculate fb_depth.
- use fb_bpp instead of fb_depth to calculate fb_stride;
we know we can divide fb_bpp.
- don't limit fb_width and fb_height by VT_FB_DEFAULT_WIDTH
and VT_FB_DEFAULT_HEIGHT (resp.). Those constants have
not relation to the size of the frame buffer.
This at least fixes "lower-resolution" Macs. We're talking
1280x1024 or so. There still is a problem with 27" Macs,
which typically have a horizontal resolution over 2K.
PR: 193745 (partial)
Ok'd by: emaste@
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.
