| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Even though the default VGA font provides box drawing fonts, there is no
guarantee any font will provide these as well (i.e. ISO-8859-*, KOI8-R).
Just use ASCII characters for box drawing.
PR: kern/141633
Notes:
svn path=/head/; revision=203659
|
| |
|
|
|
|
|
|
| |
We always build SCS, even when processing 8-bit data. There is no reason
why we should be able to disable it now.
Notes:
svn path=/head/; revision=197520
|
| |
|
|
|
|
|
|
| |
It turns out my previous commit does survive a buildkernel, but not
compilation of the individual test tools that use WARNS=6.
Notes:
svn path=/head/; revision=197471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means we can finally do things like VT100 box drawing when using
Syscons (8-bit characters). As far as I know, the only remaining issue
is the absense of proper escape sequences for special keyboard
characters (cursor, F1 to F12, etc) and xterm emulation should be ready
for general use.
Enabling xterm would have the following advantages:
- Easier possible migration to Unicode. cons25 termcap entries are very
8-bit centric. They use things like CP437 characters for box drawing,
etc.
- Better support for SSH'ing to other operating systems/devices. Most
switches use VT100-style admin interfaces.
- Reduced bandwidth, because applications can now use things like
scrolling regions.
- You can finally use applications like dtach(1) on both the console and
inside an xterm.
Notes:
svn path=/head/; revision=197470
|
|
|
I initially committed libteken to sys/dev/syscons/teken, but now that
I'm working on a console driver myself, I noticed this was not a good
decision. Move it to sys/teken to make it easier for other drivers to
use a terminal emulator.
Also list teken.c in sys/conf/files, instead of listing it in all the
files.arch files separately.
Notes:
svn path=/head/; revision=196775
|
