History log of /freebsd/sys/teken/teken.c (Results 1 – 25 of 73)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.0.0
# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

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

show more ...


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0
# cf8880d5 11-Mar-2022 Ed Maste <emaste@FreeBSD.org>

teken: color #3 is yellow not brown - use TC_YELLOW as the name

The console escape code standard (ECMA-48) specifies color #3 (escape
code 33) as yellow. A brown console color is an artifact of the

teken: color #3 is yellow not brown - use TC_YELLOW as the name

The console escape code standard (ECMA-48) specifies color #3 (escape
code 33) as yellow. A brown console color is an artifact of the VGA
palette, which replaces dim (but not bright) yellow with brown.

Reviewed by: adrian, imp
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34531

show more ...


Revision tags: release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0
# f993ed2f 09-Sep-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r351732 through r352104.


# 82625856 05-Sep-2019 Toomas Soome <tsoome@FreeBSD.org>

Adjust teken to allow build as part of loader

Building for loader needs specific headers.


Revision tags: release/11.3.0
# 8e69ae1c 05-Feb-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r343712 through r343806.


# 3a199184 05-Feb-2019 Bruce Evans <bde@FreeBSD.org>

My recent fix for programmable function keys in syscons only worked
when TEKEN_CONS25 is configured. Fix this by adding a function to
set the flag that enables the fix and always calling this functi

My recent fix for programmable function keys in syscons only worked
when TEKEN_CONS25 is configured. Fix this by adding a function to
set the flag that enables the fix and always calling this function
for syscons.

Expand the man page for teken_set_cons25(). This function is not
very useful since it can only set but not clear 1 flag. In practice,
it is only used when TEKEN_CONS25 is configured and all that does is
choose the the default emulation for syscons at compile time.

show more ...


# c2c227a5 03-Feb-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r343571 through r343711.


# 90bdbe95 01-Feb-2019 Bruce Evans <bde@FreeBSD.org>

Fix function keys for syscons in cons25 mode (vidcontrol -T cons25).

kbd(4) (but only documented in atkbd(4)) maintains a table of strings
for 96 function keys. Using teken broke this 9+ years ago

Fix function keys for syscons in cons25 mode (vidcontrol -T cons25).

kbd(4) (but only documented in atkbd(4)) maintains a table of strings
for 96 function keys. Using teken broke this 9+ years ago for the
most usable first 12 function keys and for 10 cursor keys, by supplying
its own non-programmable strings so that the keyboard driver's strings
are not used.

Fix this by supplying NULL in the teken layer for syscons in cons25 mode
so that the the strings are found in the kbd(4) layer.

vt needs more changes to use kbd(4)'s tables. Teken's cons25 table is
still needed to supply nonempty strings for vt in cons25 mode.

Keep using teken's xterm tables for both syscons and vt in xterm mode.
Function keys should at least default to xterm values in xterm mode,
and kbd(4) doesn't support this.

teken_set_cons25() sets a sticky flag to ask for the fix, and space is
reserved for another new flag. vt should set this flag when it uses
kbd(4)'s tables.

PR: 226553 (for vt)

show more ...


Revision tags: release/12.0.0, release/11.2.0
# 4812c5c5 16-May-2018 Conrad Meyer <cem@FreeBSD.org>

teken: Unbreak syscons' use of teken

Only vt(4) initializes these callbacks non-NULL at this time, so invoke the
function pointers conditionally.

Broken in r333669.

Submitted by: bde@


# 547e74a8 16-May-2018 Jean-Sébastien Pédron <dumbbell@FreeBSD.org>

teken, vt(4): New callbacks to lock the terminal once

... to process input, instead of inside each smaller operations such as
appending a character or moving the cursor forward.

In other words, bef

teken, vt(4): New callbacks to lock the terminal once

... 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

show more ...


# 92223bdd 08-Apr-2018 Poul-Henning Kamp <phk@FreeBSD.org>

Pedantic polishing of code to please FlexeLint.

Approved by: ed


# fe267a55 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: general adoption of SPDX licensing ID tags.

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
pro

sys: general adoption of SPDX licensing ID tags.

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.

No functional change intended.

show more ...


Revision tags: release/10.4.0, release/11.1.0
# 1370fa33 27-Mar-2017 Bruce Evans <bde@FreeBSD.org>

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

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.

show more ...


# 2610c9f2 16-Mar-2017 Bruce Evans <bde@FreeBSD.org>

Add teken_256to16() to convert xterm-256 256-color codes to xterm 16-color
codes. This will be used to fix bright colors.

Improve teken_256to8(). Use a lookup table instead of calculations. The
c

Add teken_256to16() to convert xterm-256 256-color codes to xterm 16-color
codes. This will be used to fix bright colors.

Improve teken_256to8(). Use a lookup table instead of calculations. The
calculations were inaccurate since they used indexes into the xterm-256
6x6x6 color map instead of actual xterm colors. Also, change the threshold
for converting to a primary color: require the primary's component to be
2 or more higher instead of just higher. This affects about 1/5 of the
table entries and gives uniformly distributed colors in the 6x6x6 submap
except for greys (35 entries each for red, green, blue, cyan, brown and
magenta, instead of approx. only 15 each for the mixed colors). Even
more mixed colors would be better for matching colors, but uniform
distribution is best for preserving contrast.

For teken_256to16(), bright colors are just the ones with luminosity >=
60%. These are actually light colors (more white instead of more
saturation), while xterm bright colors except for white itself are
actually saturated with no white, so have luminosity only 50%.

These functions are layering violations. teken cannot do correct
conversions since it shouldn't know the color maps of anything except
xterm. Translating through xterm-16 colors loses information. This
gives bugs like xterm-256 near-brown -> xterm-16 red -> VGA red.

show more ...


Revision tags: release/11.0.1, release/11.0.0, release/10.3.0
# 11d38a57 28-Oct-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head

Sponsored by: Gandi.net


# f94594b3 12-Sep-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Finish merging from head, messed up in previous attempt


# 00176600 09-Sep-2015 Navdeep Parhar <np@FreeBSD.org>

Merge r286744-r287584 from head.


# 23a32822 25-Aug-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from HEAD


# 6fdf637e 17-Aug-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r286697 through r286857.


# cd69db4b 16-Aug-2015 Ed Schouten <ed@FreeBSD.org>

Pick UINT_MAX / 100 as an upperbound.

The fix that I applied in r286798 is already good, but it assumes that
sizeof(int) > sizeof(short). Express the upperbound in terms of
UINT_MAX. By dividing tha

Pick UINT_MAX / 100 as an upperbound.

The fix that I applied in r286798 is already good, but it assumes that
sizeof(int) > sizeof(short). Express the upperbound in terms of
UINT_MAX. By dividing that by 100, we're sure that the resulting value
is never larger than approximately UINT_MAX / 10, which is safe.

PR: 202326
Discussed with: kcwu csie org
MFC after: 1 month

show more ...


# c5b3acf2 15-Aug-2015 Ed Schouten <ed@FreeBSD.org>

Stop parsing digits if the value already exceeds USHRT_MAX.

There is no need for us to support parsing values that are larger than
the maximum terminal window size. In this case that would be the ma

Stop parsing digits if the value already exceeds USHRT_MAX.

There is no need for us to support parsing values that are larger than
the maximum terminal window size. In this case that would be the maximum
of unsigned short.

The problem with parsing larger values is that they can cause integer
overflows when adjusting the cursor position, leading to all sorts of
failing assertions.

PR: 202326
Reported by: kcwu csie org
MFC after: 1 month

show more ...


Revision tags: release/10.2.0, release/10.1.0, release/9.3.0
# 6cec9cad 03-Jun-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r266724

An SVM update will follow this.


# 3b8f0845 28-Apr-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head


# 84e51a1b 23-Apr-2014 Alan Somers <asomers@FreeBSD.org>

IFC @264767


123