Commit Graph

11 Commits

Author SHA1 Message Date
Bruce Evans
1370fa3380 Oops, my fix for bright colors broke bright black some more (in cases
that used to work via the bold hack).

Fix the table entry for bright black.  Fix spelling of plain black in
nearby table entries (use the macro for black everywhere everywhere).
Fix the currently-unused non-bright color table to not have bright
colors in entries 9-15.

Improve nearby comments.  Start converting to the xterm terminology
and default rendering of "bright" instead of "light" for bright
colors.

Syscons wasn't affected by the bug since I optimized it a little by
converting colors 0-15 directly.  This also fixes the layering of
the conversion for these colors.

Apply the same optimization to vt (actually the layer above it).  This
also moves the conversion 1 closer to the correct layer for colors
0-15.

The optimization of just avoiding 2 calls to a trivial function is worth
about 10% for simple output to the virtual buffer with occasional
rendering.  The optimization is so large because the 2 calls are done
on every character, so although there are too many other calls and
other instructions per character, there are only about 10 times as
many.  Old versions of syscons were about 10 times faster for simple
output, by using a fast path with about 12 instructions per character.
Rendering to even slow hardware takes relatively little time provided
it is rarely actually done.
2017-03-27 10:48:28 +00:00
Bruce Evans
4eb235fb4f Fix bright colors for syscons, and make them work for the first time
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.
2017-03-18 11:13:54 +00:00
Jonathan T. Looney
c9cde8251c Fix a panic during boot caused by inadequate locking of some vt(4) driver
data structures.

vt_change_font() calls vtbuf_grow() to change some vt driver data
structures. It uses TF_MUTE to prevent the console from trying to use those
data structures while it changes them.

During the early stage of the boot process, the vt driver's tc_done routine
uses those data structures; however, it is currently called outside the
TF_MUTE check.

Move the tc_done routine inside the locked TF_MUTE check.

PR:		217282
Reviewed by:	ed, ray
Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D9709
2017-02-23 01:18:47 +00:00
Jean-Sébastien Pédron
da49f6bcc3 vt(4): Adjust the cursor position after changing the window size
A new terminal_set_cursor() is added: it wraps the existing
teken_set_cursor() function.

In vtbuf_grow(), the cursor position is adjusted at the end of the
function. In vt_change_font(), we call terminal_set_cursor() just after
terminal_set_winsize_blank(), while the terminal is mute.

This fixes a bug where, after loading a kernel video driver which
increases the terminal window size, the cursor remains at its old
position, in other words, in the middle of the display content.

PR:		194421
MFC after:	1 week
2014-11-01 17:05:15 +00:00
Jean-Sébastien Pédron
3e206539a1 vt(4): Add cngrab() and cnungrab() callbacks
They are used when a panic occurs or when entering a DDB session for
instance.

cngrab() forces a vt-switch to the console window, no matter if the
original window is another terminal or an X session. However, cnungrab()
doesn't vt-switch back to the original window currently.

MFC after:	1 week
2014-08-27 10:04:10 +00:00
Marius Strobl
7344ee184b In order to get vt(4) a bit closer to the feature set provided by sc(4),
implement options TERMINAL_{KERN,NORM}_ATTR. These are aliased to
SC_{KERNEL_CONS,NORM}_ATTR and like these latter, allow to change the
default colors of normal and kernel text respectively.
Note on the naming: Although affecting the output of vt(4), technically
kern/subr_terminal.c is primarily concerned with changing default colors
so it would be inconsistent to term these options VT_{KERN,NORM}_ATTR.
Actually, if the architecture and abstraction of terminal+teken+vt would
be perfect, dev/vt/* wouldn't be touched by this commit at all.

Reviewed by:	emaste
MFC after:	3 days
Sponsored by:	Bally Wulff Games & Entertainment GmbH
2014-06-27 19:57:57 +00:00
Aleksandr Rybalko
19fbe1ea90 Do not fill screen, while muted.
Sponsored by:	The FreeBSD Foundation
2014-04-07 22:37:13 +00:00
Ed Schouten
a3da01fc76 Fix copy-pasting of CJK fullwidth characters.
They are stored as two separate characters in the vtbuf, so copy-pasting
will cause them to be passed to terminal_input_char() twice. Extend
terminal_input_char() to explicitly discard characters with TF_CJK_RIGHT
set. This causes only the left part to generate input.
2013-12-24 18:42:26 +00:00
Aleksandr Rybalko
7a1a32c4ef o Add virtual terminal mmap request handler.
o Forward termianl framebuffer ioctl to fbd.
o Forward terminal mmap request to fbd.
o Move inclusion of sys/conf.h to vt.h.

Sponsored by:	The FreeBSD Foundation
2013-12-23 18:09:10 +00:00
Ed Schouten
a6c26592f1 Extend libteken to support CJK fullwidth characters.
Introduce a new formatting bit (TF_CJK_RIGHT) that is set when putting a
cell that is the right part of a CJK fullwidth character. This will
allow drivers like vt(9) to support fullwidth characters properly.

emaste@ has a patch to extend vt(9)'s font handling to increase the
number of Unicode -> glyph maps from 2 ({normal,bold)} to 4
({normal,bold} x {left,right}). This will need to use this formatting
bit to determine whether to draw the left or right glyph.

Reviewed by:	emaste
2013-12-20 21:31:50 +00:00
Aleksandr Rybalko
27cf7d04ef Merge VT(9) project (a.k.a. newcons).
Reviewed by:	nwhitehorn
MFC_to_10_after:	re approval

Sponsored by:	The FreeBSD Foundation
2013-12-05 22:38:53 +00:00