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
|
|
|
/*-
|
2017-11-27 15:23:17 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
|
|
|
|
*
|
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$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
#if defined(__FreeBSD__) && defined(_KERNEL)
|
|
|
|
#include <sys/param.h>
|
2015-08-15 08:42:33 +00:00
|
|
|
#include <sys/limits.h>
|
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
|
|
|
#include <sys/lock.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
#define teken_assert(x) MPASS(x)
|
|
|
|
#else /* !(__FreeBSD__ && _KERNEL) */
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <assert.h>
|
2015-08-15 08:42:33 +00:00
|
|
|
#include <limits.h>
|
2010-04-03 17:22:28 +00:00
|
|
|
#include <stdint.h>
|
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
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
#define teken_assert(x) assert(x)
|
|
|
|
#endif /* __FreeBSD__ && _KERNEL */
|
|
|
|
|
2011-05-09 16:27:39 +00:00
|
|
|
/* debug messages */
|
|
|
|
#define teken_printf(x,...)
|
|
|
|
|
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
|
|
|
/* Private flags for t_stateflags. */
|
2009-11-11 08:20:19 +00:00
|
|
|
#define TS_FIRSTDIGIT 0x0001 /* First numeric digit in escape sequence. */
|
|
|
|
#define TS_INSERT 0x0002 /* Insert mode. */
|
|
|
|
#define TS_AUTOWRAP 0x0004 /* Autowrap. */
|
|
|
|
#define TS_ORIGIN 0x0008 /* Origin mode. */
|
|
|
|
#define TS_WRAPPED 0x0010 /* Next character should be printed on col 0. */
|
|
|
|
#define TS_8BIT 0x0020 /* UTF-8 disabled. */
|
|
|
|
#define TS_CONS25 0x0040 /* cons25 emulation. */
|
|
|
|
#define TS_INSTRING 0x0080 /* Inside string. */
|
|
|
|
#define TS_CURSORKEYS 0x0100 /* Cursor keys mode. */
|
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
|
|
|
|
|
|
|
/* Character that blanks a cell. */
|
|
|
|
#define BLANK ' '
|
|
|
|
|
2009-09-24 20:33:14 +00:00
|
|
|
#include "teken.h"
|
|
|
|
#include "teken_wcwidth.h"
|
|
|
|
#include "teken_scs.h"
|
|
|
|
|
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 teken_state_t teken_state_init;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wrappers for hooks.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_bell(const teken_t *t)
|
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
|
|
|
{
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_bell != NULL);
|
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
|
|
|
t->t_funcs->tf_bell(t->t_softc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_cursor(const teken_t *t)
|
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
|
|
|
{
|
|
|
|
|
|
|
|
teken_assert(t->t_cursor.tp_row < t->t_winsize.tp_row);
|
|
|
|
teken_assert(t->t_cursor.tp_col < t->t_winsize.tp_col);
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_cursor != NULL);
|
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
|
|
|
t->t_funcs->tf_cursor(t->t_softc, &t->t_cursor);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_putchar(const teken_t *t, const teken_pos_t *p, teken_char_t 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
|
|
|
const teken_attr_t *a)
|
|
|
|
{
|
|
|
|
|
|
|
|
teken_assert(p->tp_row < t->t_winsize.tp_row);
|
|
|
|
teken_assert(p->tp_col < t->t_winsize.tp_col);
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_putchar != NULL);
|
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
|
|
|
t->t_funcs->tf_putchar(t->t_softc, p, c, a);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_fill(const teken_t *t, const teken_rect_t *r,
|
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
|
|
|
const teken_char_t c, const teken_attr_t *a)
|
|
|
|
{
|
|
|
|
|
|
|
|
teken_assert(r->tr_end.tp_row > r->tr_begin.tp_row);
|
|
|
|
teken_assert(r->tr_end.tp_row <= t->t_winsize.tp_row);
|
|
|
|
teken_assert(r->tr_end.tp_col > r->tr_begin.tp_col);
|
|
|
|
teken_assert(r->tr_end.tp_col <= t->t_winsize.tp_col);
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_fill != NULL);
|
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
|
|
|
t->t_funcs->tf_fill(t->t_softc, r, c, a);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_copy(const teken_t *t, const teken_rect_t *r, const teken_pos_t *p)
|
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
|
|
|
{
|
|
|
|
|
|
|
|
teken_assert(r->tr_end.tp_row > r->tr_begin.tp_row);
|
|
|
|
teken_assert(r->tr_end.tp_row <= t->t_winsize.tp_row);
|
|
|
|
teken_assert(r->tr_end.tp_col > r->tr_begin.tp_col);
|
|
|
|
teken_assert(r->tr_end.tp_col <= t->t_winsize.tp_col);
|
|
|
|
teken_assert(p->tp_row + (r->tr_end.tp_row - r->tr_begin.tp_row) <= t->t_winsize.tp_row);
|
|
|
|
teken_assert(p->tp_col + (r->tr_end.tp_col - r->tr_begin.tp_col) <= t->t_winsize.tp_col);
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_copy != NULL);
|
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
|
|
|
t->t_funcs->tf_copy(t->t_softc, r, p);
|
|
|
|
}
|
|
|
|
|
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
2018-05-16 09:01:02 +00:00
|
|
|
static inline void
|
|
|
|
teken_funcs_pre_input(const teken_t *t)
|
|
|
|
{
|
|
|
|
|
2018-05-16 18:12:49 +00:00
|
|
|
if (t->t_funcs->tf_pre_input != NULL)
|
|
|
|
t->t_funcs->tf_pre_input(t->t_softc);
|
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
2018-05-16 09:01:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
teken_funcs_post_input(const teken_t *t)
|
|
|
|
{
|
|
|
|
|
2018-05-16 18:12:49 +00:00
|
|
|
if (t->t_funcs->tf_post_input != NULL)
|
|
|
|
t->t_funcs->tf_post_input(t->t_softc);
|
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
2018-05-16 09:01:02 +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 inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_param(const teken_t *t, int cmd, unsigned int value)
|
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
|
|
|
{
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_param != NULL);
|
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
|
|
|
t->t_funcs->tf_param(t->t_softc, cmd, value);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_funcs_respond(const teken_t *t, const void *buf, size_t len)
|
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
|
|
|
{
|
|
|
|
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_assert(t->t_funcs->tf_respond != NULL);
|
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
|
|
|
t->t_funcs->tf_respond(t->t_softc, buf, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
#include "teken_subr.h"
|
|
|
|
#include "teken_subr_compat.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Programming interface.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void
|
|
|
|
teken_init(teken_t *t, const teken_funcs_t *tf, void *softc)
|
|
|
|
{
|
|
|
|
teken_pos_t tp = { .tp_row = 24, .tp_col = 80 };
|
|
|
|
|
|
|
|
t->t_funcs = tf;
|
|
|
|
t->t_softc = softc;
|
|
|
|
|
|
|
|
t->t_nextstate = teken_state_init;
|
2009-09-12 12:44:21 +00:00
|
|
|
t->t_stateflags = 0;
|
|
|
|
t->t_utf8_left = 0;
|
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
|
|
|
|
|
|
|
t->t_defattr.ta_format = 0;
|
|
|
|
t->t_defattr.ta_fgcolor = TC_WHITE;
|
|
|
|
t->t_defattr.ta_bgcolor = TC_BLACK;
|
|
|
|
teken_subr_do_reset(t);
|
|
|
|
|
|
|
|
teken_set_winsize(t, &tp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
teken_input_char(teken_t *t, teken_char_t c)
|
|
|
|
{
|
|
|
|
|
2009-10-08 10:26:49 +00:00
|
|
|
/*
|
|
|
|
* There is no support for DCS and OSC. Just discard strings
|
|
|
|
* until we receive characters that may indicate string
|
|
|
|
* termination.
|
|
|
|
*/
|
|
|
|
if (t->t_stateflags & TS_INSTRING) {
|
|
|
|
switch (c) {
|
|
|
|
case '\x1B':
|
|
|
|
t->t_stateflags &= ~TS_INSTRING;
|
|
|
|
break;
|
|
|
|
case '\a':
|
|
|
|
t->t_stateflags &= ~TS_INSTRING;
|
|
|
|
return;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
switch (c) {
|
|
|
|
case '\0':
|
|
|
|
break;
|
|
|
|
case '\a':
|
|
|
|
teken_subr_bell(t);
|
|
|
|
break;
|
|
|
|
case '\b':
|
|
|
|
teken_subr_backspace(t);
|
|
|
|
break;
|
|
|
|
case '\n':
|
|
|
|
case '\x0B':
|
|
|
|
teken_subr_newline(t);
|
|
|
|
break;
|
2009-01-05 22:09:46 +00:00
|
|
|
case '\x0C':
|
|
|
|
teken_subr_newpage(t);
|
|
|
|
break;
|
2009-01-20 11:34:28 +00:00
|
|
|
case '\x0E':
|
2009-09-12 12:44:21 +00:00
|
|
|
if (t->t_stateflags & TS_CONS25)
|
|
|
|
t->t_nextstate(t, c);
|
|
|
|
else
|
2009-09-26 15:03:42 +00:00
|
|
|
t->t_curscs = 1;
|
2009-01-20 11:34:28 +00:00
|
|
|
break;
|
|
|
|
case '\x0F':
|
2009-09-12 12:44:21 +00:00
|
|
|
if (t->t_stateflags & TS_CONS25)
|
|
|
|
t->t_nextstate(t, c);
|
|
|
|
else
|
2009-09-26 15:03:42 +00:00
|
|
|
t->t_curscs = 0;
|
2009-01-20 11:34:28 +00:00
|
|
|
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
|
|
|
case '\r':
|
|
|
|
teken_subr_carriage_return(t);
|
|
|
|
break;
|
|
|
|
case '\t':
|
|
|
|
teken_subr_horizontal_tab(t);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
t->t_nextstate(t, c);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Post-processing assertions. */
|
|
|
|
teken_assert(t->t_cursor.tp_row >= t->t_originreg.ts_begin);
|
|
|
|
teken_assert(t->t_cursor.tp_row < t->t_originreg.ts_end);
|
|
|
|
teken_assert(t->t_cursor.tp_row < t->t_winsize.tp_row);
|
|
|
|
teken_assert(t->t_cursor.tp_col < t->t_winsize.tp_col);
|
|
|
|
teken_assert(t->t_saved_cursor.tp_row < t->t_winsize.tp_row);
|
|
|
|
teken_assert(t->t_saved_cursor.tp_col < t->t_winsize.tp_col);
|
|
|
|
teken_assert(t->t_scrollreg.ts_end <= t->t_winsize.tp_row);
|
|
|
|
teken_assert(t->t_scrollreg.ts_begin < t->t_scrollreg.ts_end);
|
|
|
|
/* Origin region has to be window size or the same as scrollreg. */
|
|
|
|
teken_assert((t->t_originreg.ts_begin == t->t_scrollreg.ts_begin &&
|
|
|
|
t->t_originreg.ts_end == t->t_scrollreg.ts_end) ||
|
|
|
|
(t->t_originreg.ts_begin == 0 &&
|
|
|
|
t->t_originreg.ts_end == t->t_winsize.tp_row));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
teken_input_byte(teken_t *t, unsigned char c)
|
|
|
|
{
|
|
|
|
|
|
|
|
/*
|
|
|
|
* UTF-8 handling.
|
|
|
|
*/
|
2009-09-12 12:44:21 +00:00
|
|
|
if ((c & 0x80) == 0x00 || t->t_stateflags & TS_8BIT) {
|
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
|
|
|
/* One-byte sequence. */
|
|
|
|
t->t_utf8_left = 0;
|
|
|
|
teken_input_char(t, c);
|
|
|
|
} else if ((c & 0xe0) == 0xc0) {
|
|
|
|
/* Two-byte sequence. */
|
|
|
|
t->t_utf8_left = 1;
|
|
|
|
t->t_utf8_partial = c & 0x1f;
|
|
|
|
} else if ((c & 0xf0) == 0xe0) {
|
|
|
|
/* Three-byte sequence. */
|
|
|
|
t->t_utf8_left = 2;
|
|
|
|
t->t_utf8_partial = c & 0x0f;
|
|
|
|
} else if ((c & 0xf8) == 0xf0) {
|
|
|
|
/* Four-byte sequence. */
|
|
|
|
t->t_utf8_left = 3;
|
|
|
|
t->t_utf8_partial = c & 0x07;
|
|
|
|
} else if ((c & 0xc0) == 0x80) {
|
|
|
|
if (t->t_utf8_left == 0)
|
|
|
|
return;
|
|
|
|
t->t_utf8_left--;
|
|
|
|
t->t_utf8_partial = (t->t_utf8_partial << 6) | (c & 0x3f);
|
|
|
|
if (t->t_utf8_left == 0) {
|
2009-06-16 14:55:13 +00:00
|
|
|
teken_printf("Got UTF-8 char %x\n", t->t_utf8_partial);
|
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
|
|
|
teken_input_char(t, t->t_utf8_partial);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
teken_input(teken_t *t, const void *buf, size_t len)
|
|
|
|
{
|
|
|
|
const char *c = buf;
|
|
|
|
|
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
2018-05-16 09:01:02 +00:00
|
|
|
teken_funcs_pre_input(t);
|
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
|
|
|
while (len-- > 0)
|
|
|
|
teken_input_byte(t, *c++);
|
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
2018-05-16 09:01:02 +00:00
|
|
|
teken_funcs_post_input(t);
|
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
|
|
|
}
|
|
|
|
|
2009-09-12 12:44:21 +00:00
|
|
|
const teken_pos_t *
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_get_cursor(const teken_t *t)
|
2009-09-12 12:44:21 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
return (&t->t_cursor);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void
|
|
|
|
teken_set_cursor(teken_t *t, const teken_pos_t *p)
|
|
|
|
{
|
|
|
|
|
|
|
|
/* XXX: bounds checking with originreg! */
|
|
|
|
teken_assert(p->tp_row < t->t_winsize.tp_row);
|
|
|
|
teken_assert(p->tp_col < t->t_winsize.tp_col);
|
|
|
|
|
|
|
|
t->t_cursor = *p;
|
|
|
|
}
|
|
|
|
|
2009-02-09 15:55:21 +00:00
|
|
|
const teken_attr_t *
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_get_curattr(const teken_t *t)
|
2009-02-09 15:55:21 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
return (&t->t_curattr);
|
|
|
|
}
|
|
|
|
|
2009-03-10 11:28:54 +00:00
|
|
|
void
|
|
|
|
teken_set_curattr(teken_t *t, const teken_attr_t *a)
|
|
|
|
{
|
|
|
|
|
|
|
|
t->t_curattr = *a;
|
|
|
|
}
|
|
|
|
|
2009-02-09 15:55:21 +00:00
|
|
|
const teken_attr_t *
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_get_defattr(const teken_t *t)
|
2009-02-09 15:55:21 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
return (&t->t_defattr);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void
|
|
|
|
teken_set_defattr(teken_t *t, const teken_attr_t *a)
|
|
|
|
{
|
|
|
|
|
|
|
|
t->t_curattr = t->t_saved_curattr = t->t_defattr = *a;
|
|
|
|
}
|
|
|
|
|
2009-09-12 12:44:21 +00:00
|
|
|
const teken_pos_t *
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_get_winsize(const teken_t *t)
|
2009-09-12 12:44:21 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
return (&t->t_winsize);
|
|
|
|
}
|
|
|
|
|
2014-02-06 11:38:39 +00:00
|
|
|
static void
|
2014-02-06 13:28:06 +00:00
|
|
|
teken_trim_cursor_pos(teken_t *t, const teken_pos_t *new)
|
2014-02-06 11:38:39 +00:00
|
|
|
{
|
|
|
|
const teken_pos_t *cur;
|
|
|
|
|
|
|
|
cur = &t->t_winsize;
|
|
|
|
|
|
|
|
if (cur->tp_row < new->tp_row || cur->tp_col < new->tp_col)
|
|
|
|
return;
|
|
|
|
if (t->t_cursor.tp_row >= new->tp_row)
|
|
|
|
t->t_cursor.tp_row = new->tp_row - 1;
|
|
|
|
if (t->t_cursor.tp_col >= new->tp_col)
|
|
|
|
t->t_cursor.tp_col = new->tp_col - 1;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void
|
|
|
|
teken_set_winsize(teken_t *t, const teken_pos_t *p)
|
|
|
|
{
|
|
|
|
|
2014-02-06 13:28:06 +00:00
|
|
|
teken_trim_cursor_pos(t, p);
|
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
|
|
|
t->t_winsize = *p;
|
2009-09-12 08:19:24 +00:00
|
|
|
teken_subr_do_reset(t);
|
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
|
|
|
}
|
|
|
|
|
2013-12-05 22:38:53 +00:00
|
|
|
void
|
|
|
|
teken_set_winsize_noreset(teken_t *t, const teken_pos_t *p)
|
|
|
|
{
|
|
|
|
|
2014-02-06 13:28:06 +00:00
|
|
|
teken_trim_cursor_pos(t, p);
|
2013-12-05 22:38:53 +00:00
|
|
|
t->t_winsize = *p;
|
|
|
|
teken_subr_do_resize(t);
|
|
|
|
}
|
|
|
|
|
2009-09-12 10:34:34 +00:00
|
|
|
void
|
|
|
|
teken_set_8bit(teken_t *t)
|
|
|
|
{
|
|
|
|
|
2009-09-12 12:44:21 +00:00
|
|
|
t->t_stateflags |= TS_8BIT;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
teken_set_cons25(teken_t *t)
|
|
|
|
{
|
|
|
|
|
|
|
|
t->t_stateflags |= TS_CONS25;
|
2009-09-12 10:34:34 +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
|
|
|
/*
|
|
|
|
* State machine.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
teken_state_switch(teken_t *t, teken_state_t *s)
|
|
|
|
{
|
|
|
|
|
|
|
|
t->t_nextstate = s;
|
|
|
|
t->t_curnum = 0;
|
|
|
|
t->t_stateflags |= TS_FIRSTDIGIT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
teken_state_numbers(teken_t *t, teken_char_t c)
|
|
|
|
{
|
|
|
|
|
|
|
|
teken_assert(t->t_curnum < T_NUMSIZE);
|
|
|
|
|
|
|
|
if (c >= '0' && c <= '9') {
|
|
|
|
if (t->t_stateflags & TS_FIRSTDIGIT) {
|
2015-08-15 08:42:33 +00:00
|
|
|
/* First digit. */
|
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
|
|
|
t->t_stateflags &= ~TS_FIRSTDIGIT;
|
2015-08-15 08:42:33 +00:00
|
|
|
t->t_nums[t->t_curnum] = c - '0';
|
2015-08-16 13:59:11 +00:00
|
|
|
} else if (t->t_nums[t->t_curnum] < UINT_MAX / 100) {
|
2015-08-15 08:42:33 +00:00
|
|
|
/*
|
2015-08-16 13:59:11 +00:00
|
|
|
* There is no need to continue parsing input
|
|
|
|
* once the value exceeds the size of the
|
|
|
|
* terminal. It would only allow for integer
|
|
|
|
* overflows when performing arithmetic on the
|
|
|
|
* cursor position.
|
|
|
|
*
|
|
|
|
* Ignore any further digits if the value is
|
|
|
|
* already UINT_MAX / 100.
|
2015-08-15 08:42:33 +00:00
|
|
|
*/
|
|
|
|
t->t_nums[t->t_curnum] =
|
|
|
|
t->t_nums[t->t_curnum] * 10 + c - '0';
|
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
|
|
|
}
|
|
|
|
return (1);
|
|
|
|
} else if (c == ';') {
|
|
|
|
if (t->t_stateflags & TS_FIRSTDIGIT)
|
|
|
|
t->t_nums[t->t_curnum] = 0;
|
|
|
|
|
|
|
|
/* Only allow a limited set of arguments. */
|
|
|
|
if (++t->t_curnum == T_NUMSIZE) {
|
|
|
|
teken_state_switch(t, teken_state_init);
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
t->t_stateflags |= TS_FIRSTDIGIT;
|
|
|
|
return (1);
|
|
|
|
} else {
|
|
|
|
if (t->t_stateflags & TS_FIRSTDIGIT && t->t_curnum > 0) {
|
|
|
|
/* Finish off the last empty argument. */
|
|
|
|
t->t_nums[t->t_curnum] = 0;
|
|
|
|
t->t_curnum++;
|
|
|
|
} else if ((t->t_stateflags & TS_FIRSTDIGIT) == 0) {
|
|
|
|
/* Also count the last argument. */
|
|
|
|
t->t_curnum++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
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.
2017-03-16 16:40:54 +00:00
|
|
|
#define k TC_BLACK
|
|
|
|
#define b TC_BLUE
|
|
|
|
#define y TC_BROWN
|
|
|
|
#define c TC_CYAN
|
|
|
|
#define g TC_GREEN
|
|
|
|
#define m TC_MAGENTA
|
|
|
|
#define r TC_RED
|
|
|
|
#define w TC_WHITE
|
|
|
|
#define K (TC_BLACK | TC_LIGHT)
|
|
|
|
#define B (TC_BLUE | TC_LIGHT)
|
|
|
|
#define Y (TC_BROWN | TC_LIGHT)
|
|
|
|
#define C (TC_CYAN | TC_LIGHT)
|
|
|
|
#define G (TC_GREEN | TC_LIGHT)
|
|
|
|
#define M (TC_MAGENTA | TC_LIGHT)
|
|
|
|
#define R (TC_RED | TC_LIGHT)
|
|
|
|
#define W (TC_WHITE | TC_LIGHT)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The xterm-256 color map has steps of 0x28 (in the range 0-0xff), except
|
|
|
|
* for the first step which is 0x5f. Scale to the range 0-6 by dividing
|
|
|
|
* by 0x28 and rounding down. The range of 0-5 cannot represent the
|
|
|
|
* larger first step.
|
|
|
|
*
|
|
|
|
* This table is generated by the follow rules:
|
|
|
|
* - if all components are equal, the result is black for (0, 0, 0) and
|
|
|
|
* (2, 2, 2), else white; otherwise:
|
|
|
|
* - subtract the smallest component from all components
|
|
|
|
* - if this gives only one nonzero component, then that is the color
|
|
|
|
* - else if one component is 2 or more larger than the other nonzero one,
|
|
|
|
* then that component gives the color
|
|
|
|
* - else there are 2 nonzero components. The color is that of a small
|
|
|
|
* equal mixture of these components (cyan, yellow or magenta). E.g.,
|
|
|
|
* (0, 5, 6) (Turquoise2) is a much purer cyan than (0, 2, 3)
|
|
|
|
* (DeepSkyBlue4), but we map both to cyan since we can't represent
|
|
|
|
* delicate shades of either blue or cyan and blue would be worse.
|
|
|
|
* Here it is important that components of 1 never occur. Blue would
|
|
|
|
* be twice as large as green in (0, 1, 2).
|
|
|
|
*/
|
|
|
|
static const teken_color_t teken_256to8tab[] = {
|
2017-03-27 10:48:28 +00:00
|
|
|
/* xterm normal colors: */
|
|
|
|
k, r, g, y, b, m, c, w,
|
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.
2017-03-16 16:40:54 +00:00
|
|
|
|
2017-03-27 10:48:28 +00:00
|
|
|
/* xterm bright colors: */
|
|
|
|
k, r, g, y, b, m, c, w,
|
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.
2017-03-16 16:40:54 +00:00
|
|
|
|
|
|
|
/* Red0 submap. */
|
|
|
|
k, b, b, b, b, b,
|
|
|
|
g, c, c, b, b, b,
|
|
|
|
g, c, c, c, b, b,
|
|
|
|
g, g, c, c, c, b,
|
|
|
|
g, g, g, c, c, c,
|
|
|
|
g, g, g, g, c, c,
|
|
|
|
|
|
|
|
/* Red2 submap. */
|
|
|
|
r, m, m, b, b, b,
|
|
|
|
y, k, b, b, b, b,
|
|
|
|
y, g, c, c, b, b,
|
|
|
|
g, g, c, c, c, b,
|
|
|
|
g, g, g, c, c, c,
|
|
|
|
g, g, g, g, c, c,
|
|
|
|
|
|
|
|
/* Red3 submap. */
|
|
|
|
r, m, m, m, b, b,
|
|
|
|
y, r, m, m, b, b,
|
|
|
|
y, y, w, b, b, b,
|
|
|
|
y, y, g, c, c, b,
|
|
|
|
g, g, g, c, c, c,
|
|
|
|
g, g, g, g, c, c,
|
|
|
|
|
|
|
|
/* Red4 submap. */
|
|
|
|
r, r, m, m, m, b,
|
|
|
|
r, r, m, m, m, b,
|
|
|
|
y, y, r, m, m, b,
|
|
|
|
y, y, y, w, b, b,
|
|
|
|
y, y, y, g, c, c,
|
|
|
|
g, g, g, g, c, c,
|
|
|
|
|
|
|
|
/* Red5 submap. */
|
|
|
|
r, r, r, m, m, m,
|
|
|
|
r, r, r, m, m, m,
|
|
|
|
r, r, r, m, m, m,
|
|
|
|
y, y, y, r, m, m,
|
|
|
|
y, y, y, y, w, b,
|
|
|
|
y, y, y, y, g, c,
|
|
|
|
|
|
|
|
/* Red6 submap. */
|
|
|
|
r, r, r, r, m, m,
|
|
|
|
r, r, r, r, m, m,
|
|
|
|
r, r, r, r, m, m,
|
|
|
|
r, r, r, r, m, m,
|
|
|
|
y, y, y, y, r, m,
|
|
|
|
y, y, y, y, y, w,
|
|
|
|
|
|
|
|
/* Grey submap. */
|
|
|
|
k, k, k, k, k, k,
|
|
|
|
k, k, k, k, k, k,
|
|
|
|
w, w, w, w, w, w,
|
|
|
|
w, w, w, w, w, w,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This table is generated from the previous one by setting TC_LIGHT for
|
|
|
|
* entries whose luminosity in the xterm256 color map is 60% or larger.
|
|
|
|
* Thus the previous table is currently not really needed. It will be
|
|
|
|
* used for different fine tuning of the tables.
|
|
|
|
*/
|
|
|
|
static const teken_color_t teken_256to16tab[] = {
|
2017-03-27 10:48:28 +00:00
|
|
|
/* xterm normal colors: */
|
|
|
|
k, r, g, y, b, m, c, w,
|
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.
2017-03-16 16:40:54 +00:00
|
|
|
|
2017-03-27 10:48:28 +00:00
|
|
|
/* xterm bright colors: */
|
|
|
|
K, R, G, Y, B, M, C, W,
|
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.
2017-03-16 16:40:54 +00:00
|
|
|
|
|
|
|
/* Red0 submap. */
|
|
|
|
k, b, b, b, b, b,
|
|
|
|
g, c, c, b, b, b,
|
|
|
|
g, c, c, c, b, b,
|
|
|
|
g, g, c, c, c, b,
|
|
|
|
g, g, g, c, c, c,
|
|
|
|
g, g, g, g, c, c,
|
|
|
|
|
|
|
|
/* Red2 submap. */
|
|
|
|
r, m, m, b, b, b,
|
|
|
|
y, K, b, b, B, B,
|
|
|
|
y, g, c, c, B, B,
|
|
|
|
g, g, c, c, C, B,
|
|
|
|
g, G, G, C, C, C,
|
|
|
|
g, G, G, G, C, C,
|
|
|
|
|
|
|
|
/* Red3 submap. */
|
|
|
|
r, m, m, m, b, b,
|
|
|
|
y, r, m, m, B, B,
|
|
|
|
y, y, w, B, B, B,
|
|
|
|
y, y, G, C, C, B,
|
|
|
|
g, G, G, C, C, C,
|
|
|
|
g, G, G, G, C, C,
|
|
|
|
|
|
|
|
/* Red4 submap. */
|
|
|
|
r, r, m, m, m, b,
|
|
|
|
r, r, m, m, M, B,
|
|
|
|
y, y, R, M, M, B,
|
|
|
|
y, y, Y, W, B, B,
|
|
|
|
y, Y, Y, G, C, C,
|
|
|
|
g, G, G, G, C, C,
|
|
|
|
|
|
|
|
/* Red5 submap. */
|
|
|
|
r, r, r, m, m, m,
|
|
|
|
r, R, R, M, M, M,
|
|
|
|
r, R, R, M, M, M,
|
|
|
|
y, Y, Y, R, M, M,
|
|
|
|
y, Y, Y, Y, W, B,
|
|
|
|
y, Y, Y, Y, G, C,
|
|
|
|
|
|
|
|
/* Red6 submap. */
|
|
|
|
r, r, r, r, m, m,
|
|
|
|
r, R, R, R, M, M,
|
|
|
|
r, R, R, R, M, M,
|
|
|
|
r, R, R, R, M, M,
|
|
|
|
y, Y, Y, Y, R, M,
|
|
|
|
y, Y, Y, Y, Y, W,
|
|
|
|
|
|
|
|
/* Grey submap. */
|
|
|
|
k, k, k, k, k, k,
|
|
|
|
K, K, K, K, K, K,
|
|
|
|
w, w, w, w, w, w,
|
|
|
|
W, W, W, W, W, W,
|
|
|
|
};
|
|
|
|
|
|
|
|
#undef k
|
|
|
|
#undef b
|
|
|
|
#undef y
|
|
|
|
#undef c
|
|
|
|
#undef g
|
|
|
|
#undef m
|
|
|
|
#undef r
|
|
|
|
#undef w
|
|
|
|
#undef K
|
|
|
|
#undef B
|
|
|
|
#undef Y
|
|
|
|
#undef C
|
|
|
|
#undef G
|
|
|
|
#undef M
|
|
|
|
#undef R
|
|
|
|
#undef W
|
|
|
|
|
2009-09-26 15:26:32 +00:00
|
|
|
teken_color_t
|
|
|
|
teken_256to8(teken_color_t 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.
2017-03-16 16:40:54 +00:00
|
|
|
return (teken_256to8tab[c % 256]);
|
|
|
|
}
|
|
|
|
|
|
|
|
teken_color_t
|
|
|
|
teken_256to16(teken_color_t c)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (teken_256to16tab[c % 256]);
|
2009-09-26 15:26:32 +00:00
|
|
|
}
|
|
|
|
|
2009-11-11 08:20:19 +00:00
|
|
|
static const char * const special_strings_cons25[] = {
|
|
|
|
[TKEY_UP] = "\x1B[A", [TKEY_DOWN] = "\x1B[B",
|
|
|
|
[TKEY_LEFT] = "\x1B[D", [TKEY_RIGHT] = "\x1B[C",
|
|
|
|
|
|
|
|
[TKEY_HOME] = "\x1B[H", [TKEY_END] = "\x1B[F",
|
2009-11-11 09:43:26 +00:00
|
|
|
[TKEY_INSERT] = "\x1B[L", [TKEY_DELETE] = "\x7F",
|
2009-11-11 08:20:19 +00:00
|
|
|
[TKEY_PAGE_UP] = "\x1B[I", [TKEY_PAGE_DOWN] = "\x1B[G",
|
|
|
|
|
|
|
|
[TKEY_F1] = "\x1B[M", [TKEY_F2] = "\x1B[N",
|
|
|
|
[TKEY_F3] = "\x1B[O", [TKEY_F4] = "\x1B[P",
|
|
|
|
[TKEY_F5] = "\x1B[Q", [TKEY_F6] = "\x1B[R",
|
|
|
|
[TKEY_F7] = "\x1B[S", [TKEY_F8] = "\x1B[T",
|
|
|
|
[TKEY_F9] = "\x1B[U", [TKEY_F10] = "\x1B[V",
|
|
|
|
[TKEY_F11] = "\x1B[W", [TKEY_F12] = "\x1B[X",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const special_strings_ckeys[] = {
|
|
|
|
[TKEY_UP] = "\x1BOA", [TKEY_DOWN] = "\x1BOB",
|
|
|
|
[TKEY_LEFT] = "\x1BOD", [TKEY_RIGHT] = "\x1BOC",
|
|
|
|
|
|
|
|
[TKEY_HOME] = "\x1BOH", [TKEY_END] = "\x1BOF",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const special_strings_normal[] = {
|
|
|
|
[TKEY_UP] = "\x1B[A", [TKEY_DOWN] = "\x1B[B",
|
|
|
|
[TKEY_LEFT] = "\x1B[D", [TKEY_RIGHT] = "\x1B[C",
|
|
|
|
|
|
|
|
[TKEY_HOME] = "\x1B[H", [TKEY_END] = "\x1B[F",
|
2009-11-11 09:43:26 +00:00
|
|
|
[TKEY_INSERT] = "\x1B[2~", [TKEY_DELETE] = "\x1B[3~",
|
2009-11-11 08:20:19 +00:00
|
|
|
[TKEY_PAGE_UP] = "\x1B[5~", [TKEY_PAGE_DOWN] = "\x1B[6~",
|
|
|
|
|
|
|
|
[TKEY_F1] = "\x1BOP", [TKEY_F2] = "\x1BOQ",
|
|
|
|
[TKEY_F3] = "\x1BOR", [TKEY_F4] = "\x1BOS",
|
|
|
|
[TKEY_F5] = "\x1B[15~", [TKEY_F6] = "\x1B[17~",
|
|
|
|
[TKEY_F7] = "\x1B[18~", [TKEY_F8] = "\x1B[19~",
|
|
|
|
[TKEY_F9] = "\x1B[20~", [TKEY_F10] = "\x1B[21~",
|
|
|
|
[TKEY_F11] = "\x1B[23~", [TKEY_F12] = "\x1B[24~",
|
|
|
|
};
|
|
|
|
|
|
|
|
const char *
|
2018-04-08 19:23:50 +00:00
|
|
|
teken_get_sequence(const teken_t *t, unsigned int k)
|
2009-11-11 08:20:19 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
/* Cons25 mode. */
|
|
|
|
if (t->t_stateflags & TS_CONS25 &&
|
|
|
|
k < sizeof special_strings_cons25 / sizeof(char *))
|
|
|
|
return (special_strings_cons25[k]);
|
|
|
|
|
|
|
|
/* Cursor keys mode. */
|
|
|
|
if (t->t_stateflags & TS_CURSORKEYS &&
|
|
|
|
k < sizeof special_strings_ckeys / sizeof(char *))
|
|
|
|
return (special_strings_ckeys[k]);
|
|
|
|
|
|
|
|
/* Default xterm sequences. */
|
|
|
|
if (k < sizeof special_strings_normal / sizeof(char *))
|
|
|
|
return (special_strings_normal[k]);
|
2011-06-26 18:25:10 +00:00
|
|
|
|
2009-11-11 08:20:19 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
#include "teken_state.h"
|