Replace syscons terminal renderer by a new renderer that uses libteken.
Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen contents, but only
keeps terminal state, such as cursor position, attributes, etc. It
should implement all escape sequences that are implemented by the
cons25 terminal emulator, but also a fair amount of sequences that are
present in VT100 and xterm.
A lot of random notes, which could be of interest to users/developers:
- Even though I'm leaving the terminal type set to `cons25', users can
do experiments with placing `xterm-color' in /etc/ttys. Because we
only implement a subset of features of xterm, this may cause
artifacts. We should consider extending libteken, because in my
opinion xterm is the way to go. Some missing features:
- Keypad application mode (DECKPAM)
- Character sets (SCS)
- libteken is filled with a fair amount of assertions, but unfortunately
we cannot go into the debugger anymore if we fail them. I've done
development of this library almost entirely in userspace. In
sys/dev/syscons/teken there are two applications that can be helpful
when debugging the code:
- teken_demo: a terminal emulator that can be started from a regular
xterm that emulates a terminal using libteken. This application can
be very useful to debug any rendering issues.
- teken_stress: a stress testing application that emulates random
terminal output. libteken has literally survived multiple terabytes
of random input.
- libteken also includes support for UTF-8, but unfortunately our input
layer and font renderer don't support this. If users want to
experiment with UTF-8 support, they can enable `TEKEN_UTF8' in
teken.h. If you recompile your kernel or the teken_demo application,
you can hold some nice experiments.
- I've left PC98 the way it is right now. The PC98 platform has a custom
syscons renderer, which supports some form of localised input. Maybe
we should port PC98 to libteken by the time syscons supports UTF-8?
- I've removed the `dumb' terminal emulator. It has been broken for
years. It hasn't survived the `struct proc' -> `struct thread'
conversion.
- To prevent confusion among people that want to hack on libteken:
unlike syscons, the state machines that parse the escape sequences are
machine generated. This means that if you want to add new escape
sequences, you have to add an entry to the `sequences' file. This will
cause new entries to be added to `teken_state.h'.
- Any rendering artifacts that didn't occur prior to this commit are by
accident. They should be reported to me, so I can fix them.
Discussed on: current@, hackers@
Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
|
|
|
/*-
|
|
|
|
|
* Copyright (c) 2008-2009 Ed Schouten <ed@FreeBSD.org>
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
2017-08-18 10:38:49 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_adapter_border(teken_t *t, unsigned int c)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
teken_funcs_param(t, TP_SETBORDER, c);
|
|
|
|
|
}
|
|
|
|
|
|
Replace syscons terminal renderer by a new renderer that uses libteken.
Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen contents, but only
keeps terminal state, such as cursor position, attributes, etc. It
should implement all escape sequences that are implemented by the
cons25 terminal emulator, but also a fair amount of sequences that are
present in VT100 and xterm.
A lot of random notes, which could be of interest to users/developers:
- Even though I'm leaving the terminal type set to `cons25', users can
do experiments with placing `xterm-color' in /etc/ttys. Because we
only implement a subset of features of xterm, this may cause
artifacts. We should consider extending libteken, because in my
opinion xterm is the way to go. Some missing features:
- Keypad application mode (DECKPAM)
- Character sets (SCS)
- libteken is filled with a fair amount of assertions, but unfortunately
we cannot go into the debugger anymore if we fail them. I've done
development of this library almost entirely in userspace. In
sys/dev/syscons/teken there are two applications that can be helpful
when debugging the code:
- teken_demo: a terminal emulator that can be started from a regular
xterm that emulates a terminal using libteken. This application can
be very useful to debug any rendering issues.
- teken_stress: a stress testing application that emulates random
terminal output. libteken has literally survived multiple terabytes
of random input.
- libteken also includes support for UTF-8, but unfortunately our input
layer and font renderer don't support this. If users want to
experiment with UTF-8 support, they can enable `TEKEN_UTF8' in
teken.h. If you recompile your kernel or the teken_demo application,
you can hold some nice experiments.
- I've left PC98 the way it is right now. The PC98 platform has a custom
syscons renderer, which supports some form of localised input. Maybe
we should port PC98 to libteken by the time syscons supports UTF-8?
- I've removed the `dumb' terminal emulator. It has been broken for
years. It hasn't survived the `struct proc' -> `struct thread'
conversion.
- To prevent confusion among people that want to hack on libteken:
unlike syscons, the state machines that parse the escape sequences are
machine generated. This means that if you want to add new escape
sequences, you have to add an entry to the `sequences' file. This will
cause new entries to be added to `teken_state.h'.
- Any rendering artifacts that didn't occur prior to this commit are by
accident. They should be reported to me, so I can fix them.
Discussed on: current@, hackers@
Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_cursor_type(teken_t *t, unsigned int type)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
teken_funcs_param(t, TP_SHOWCURSOR, type != 1);
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-18 09:44:33 +00:00
|
|
|
static const teken_color_t cons25_colors[8] = { TC_BLACK, TC_BLUE,
|
|
|
|
|
TC_GREEN, TC_CYAN, TC_RED, TC_MAGENTA, TC_BROWN, TC_WHITE };
|
2009-01-17 23:01:40 +00:00
|
|
|
|
2009-01-17 22:53:53 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_adapter_background(teken_t *t, unsigned int c)
|
|
|
|
|
{
|
|
|
|
|
|
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
|
|
|
t->t_defattr.ta_bgcolor = cons25_colors[c % 8] | (c & 8);
|
|
|
|
|
t->t_curattr.ta_bgcolor = cons25_colors[c % 8] | (c & 8);
|
2009-01-17 22:53:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_adapter_foreground(teken_t *t, unsigned int c)
|
|
|
|
|
{
|
|
|
|
|
|
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
|
|
|
t->t_defattr.ta_fgcolor = cons25_colors[c % 8] | (c & 8);
|
|
|
|
|
t->t_curattr.ta_fgcolor = cons25_colors[c % 8] | (c & 8);
|
2009-01-17 22:53:53 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-12 12:44:21 +00:00
|
|
|
static const teken_color_t cons25_revcolors[8] = { 0, 4, 2, 6, 1, 5, 3, 7 };
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
teken_get_defattr_cons25(teken_t *t, int *fg, int *bg)
|
|
|
|
|
{
|
|
|
|
|
|
2009-09-26 15:26:32 +00:00
|
|
|
*fg = cons25_revcolors[teken_256to8(t->t_defattr.ta_fgcolor)];
|
2009-09-12 12:44:21 +00:00
|
|
|
if (t->t_defattr.ta_format & TF_BOLD)
|
|
|
|
|
*fg += 8;
|
2009-09-26 15:26:32 +00:00
|
|
|
*bg = cons25_revcolors[teken_256to8(t->t_defattr.ta_bgcolor)];
|
2009-09-12 12:44:21 +00:00
|
|
|
}
|
|
|
|
|
|
Replace syscons terminal renderer by a new renderer that uses libteken.
Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen contents, but only
keeps terminal state, such as cursor position, attributes, etc. It
should implement all escape sequences that are implemented by the
cons25 terminal emulator, but also a fair amount of sequences that are
present in VT100 and xterm.
A lot of random notes, which could be of interest to users/developers:
- Even though I'm leaving the terminal type set to `cons25', users can
do experiments with placing `xterm-color' in /etc/ttys. Because we
only implement a subset of features of xterm, this may cause
artifacts. We should consider extending libteken, because in my
opinion xterm is the way to go. Some missing features:
- Keypad application mode (DECKPAM)
- Character sets (SCS)
- libteken is filled with a fair amount of assertions, but unfortunately
we cannot go into the debugger anymore if we fail them. I've done
development of this library almost entirely in userspace. In
sys/dev/syscons/teken there are two applications that can be helpful
when debugging the code:
- teken_demo: a terminal emulator that can be started from a regular
xterm that emulates a terminal using libteken. This application can
be very useful to debug any rendering issues.
- teken_stress: a stress testing application that emulates random
terminal output. libteken has literally survived multiple terabytes
of random input.
- libteken also includes support for UTF-8, but unfortunately our input
layer and font renderer don't support this. If users want to
experiment with UTF-8 support, they can enable `TEKEN_UTF8' in
teken.h. If you recompile your kernel or the teken_demo application,
you can hold some nice experiments.
- I've left PC98 the way it is right now. The PC98 platform has a custom
syscons renderer, which supports some form of localised input. Maybe
we should port PC98 to libteken by the time syscons supports UTF-8?
- I've removed the `dumb' terminal emulator. It has been broken for
years. It hasn't survived the `struct proc' -> `struct thread'
conversion.
- To prevent confusion among people that want to hack on libteken:
unlike syscons, the state machines that parse the escape sequences are
machine generated. This means that if you want to add new escape
sequences, you have to add an entry to the `sequences' file. This will
cause new entries to be added to `teken_state.h'.
- Any rendering artifacts that didn't occur prior to this commit are by
accident. They should be reported to me, so I can fix them.
Discussed on: current@, hackers@
Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_switch_virtual_terminal(teken_t *t, unsigned int vt)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
teken_funcs_param(t, TP_SWITCHVT, vt);
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-31 19:35:41 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_bell_pitch_duration(teken_t *t, unsigned int pitch,
|
|
|
|
|
unsigned int duration)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
teken_funcs_param(t, TP_SETBELLPD, (pitch << 16) |
|
|
|
|
|
(duration & 0xffff));
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-05 00:56:21 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_graphic_rendition(teken_t *t, unsigned int cmd,
|
|
|
|
|
unsigned int param __unused)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
|
case 0: /* Reset. */
|
|
|
|
|
t->t_curattr = t->t_defattr;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
teken_printf("unsupported attribute %u\n", cmd);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-25 13:51:01 +00:00
|
|
|
static void
|
|
|
|
|
teken_subr_cons25_set_terminal_mode(teken_t *t, unsigned int mode)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
switch (mode) {
|
|
|
|
|
case 0: /* Switch terminal to xterm. */
|
|
|
|
|
t->t_stateflags &= ~TS_CONS25;
|
|
|
|
|
break;
|
|
|
|
|
case 1: /* Switch terminal to cons25. */
|
|
|
|
|
t->t_stateflags |= TS_CONS25;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Replace syscons terminal renderer by a new renderer that uses libteken.
Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen contents, but only
keeps terminal state, such as cursor position, attributes, etc. It
should implement all escape sequences that are implemented by the
cons25 terminal emulator, but also a fair amount of sequences that are
present in VT100 and xterm.
A lot of random notes, which could be of interest to users/developers:
- Even though I'm leaving the terminal type set to `cons25', users can
do experiments with placing `xterm-color' in /etc/ttys. Because we
only implement a subset of features of xterm, this may cause
artifacts. We should consider extending libteken, because in my
opinion xterm is the way to go. Some missing features:
- Keypad application mode (DECKPAM)
- Character sets (SCS)
- libteken is filled with a fair amount of assertions, but unfortunately
we cannot go into the debugger anymore if we fail them. I've done
development of this library almost entirely in userspace. In
sys/dev/syscons/teken there are two applications that can be helpful
when debugging the code:
- teken_demo: a terminal emulator that can be started from a regular
xterm that emulates a terminal using libteken. This application can
be very useful to debug any rendering issues.
- teken_stress: a stress testing application that emulates random
terminal output. libteken has literally survived multiple terabytes
of random input.
- libteken also includes support for UTF-8, but unfortunately our input
layer and font renderer don't support this. If users want to
experiment with UTF-8 support, they can enable `TEKEN_UTF8' in
teken.h. If you recompile your kernel or the teken_demo application,
you can hold some nice experiments.
- I've left PC98 the way it is right now. The PC98 platform has a custom
syscons renderer, which supports some form of localised input. Maybe
we should port PC98 to libteken by the time syscons supports UTF-8?
- I've removed the `dumb' terminal emulator. It has been broken for
years. It hasn't survived the `struct proc' -> `struct thread'
conversion.
- To prevent confusion among people that want to hack on libteken:
unlike syscons, the state machines that parse the escape sequences are
machine generated. This means that if you want to add new escape
sequences, you have to add an entry to the `sequences' file. This will
cause new entries to be added to `teken_state.h'.
- Any rendering artifacts that didn't occur prior to this commit are by
accident. They should be reported to me, so I can fix them.
Discussed on: current@, hackers@
Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
|
|
|
#if 0
|
|
|
|
|
static void
|
|
|
|
|
teken_subr_vt52_decid(teken_t *t)
|
|
|
|
|
{
|
|
|
|
|
const char response[] = "\x1B/Z";
|
|
|
|
|
|
|
|
|
|
teken_funcs_respond(t, response, sizeof response - 1);
|
|
|
|
|
}
|
|
|
|
|
#endif
|