| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/
|
| |
|
|
| |
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| |
|
|
| |
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.
Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.
Notes:
svn path=/head/; revision=366304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=343778
|
| |
|
|
|
|
|
| |
Approved by: ed
Notes:
svn path=/head/; revision=332297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=315418
|
| |
|
|
| |
Notes:
svn path=/head/; revision=276292
|
| |
|
|
| |
Notes:
svn path=/head/; revision=226111
|
| |
|
|
| |
Notes:
svn path=/head/; revision=223574
|
| |
|
|
| |
Notes:
svn path=/head/; revision=222600
|
|
|
I'm not sure whether we should install teken as a library on any stock
FreeBSD installation, but I can imagine people want to tinker around
with it now and then. Create a /sys/teken/libteken, which holds a
Makefile to install a shared library version of the terminal emulator,
complete with a manpage.
Also add Makefiles for the demo/stress applications, to build it against
the shared library.
Notes:
svn path=/head/; revision=221698
|
