There is no need to try to resume it after each smaller operations
(putchar, cursor_position, copy, fill).
The resume function already checks if the timer is armed before doing
anything, but it uses an atomic cmpset which is expensive. And resuming
the timer at the end of input processing is enough.
While here, we also skip timer resume if the input is for another
windows than the currently displayed one. I.e. if `ttyv0` is currently
displayed, any changes to `ttyv1` shouldn't resume the timer (which
would refresh `ttyv0`).
By doing the same benchmark as r333669, I get:
* vt(4), before r333669: 1500 ms
* vt(4), with this patch: 760 ms
* syscons(4): 700 ms
... to process input, instead of inside each smaller operations such as
appending a character or moving the cursor forward.
In other words, before we were doing (oversimplified):
teken_input()
<for each input character>
vtterm_putchar()
VTBUF_LOCK()
VTBUF_UNLOCK()
vtterm_cursor_position()
VTBUF_LOCK()
VTBUF_UNLOCK()
Now, we are doing:
vtterm_pre_input()
VTBUF_LOCK()
teken_input()
<for each input character>
vtterm_putchar()
vtterm_cursor_position()
vtterm_post_input()
VTBUF_UNLOCK()
The situation was even worse when the vtterm_copy() and vtterm_fill()
callbacks were involved.
The new callbacks are:
* struct terminal_class->tc_pre_input()
* struct terminal_class->tc_post_input()
They are called in teken_input(), surrounding the while() loop.
The goal is to improve input processing speed of vt(4). As a benchmark,
here is the time taken to write a text file of 360 000 lines (26 MiB) on
`ttyv0`:
* vt(4), unmodified: 1500 ms
* vt(4), with this patch: 1200 ms
* syscons(4): 700 ms
This is on a Haswell laptop with a GENERIC-NODEBUG kernel.
At the same time, the locking is changed in the vt_flush() function
which is responsible to draw the text on screen. So instead of
(indirectly) using VTBUF_LOCK() just to read and reset the dirty area
of the internal buffer, the lock is held for about the entire function,
including the drawing part.
The change is mostly visible while content is scrolling fast: before,
lines could appear garbled while scrolling because the internal buffer
was accessed without locks (once the scrolling was finished, the output
was correct). Now, the scrolling appears correct.
In the end, the locking model is closer to what syscons(4) does.
Differential Revision: https://reviews.freebsd.org/D15302
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
This makes it more logical:
1. It checks the requested color format
2. It fills the palette accordingly
Also vt_palette_init() is only called when needed (i.e. when the format
is `COLOR_FORMAT_RGB`).
"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@
