d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
eba77f5c40
freebsd-skq/sys/dev/syscons/scterm-teken.c

650 lines
17 KiB
C
Raw Normal View History

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) 1999 Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
* All rights reserved.
*
* 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 as
* the first lines of this file unmodified.
* 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 AUTHORS ``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 AUTHORS 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.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include "opt_syscons.h"
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/kernel.h>
#include <sys/module.h>
#include <sys/consio.h>
#if defined(__sparc64__) || defined(__powerpc__)
#include <machine/sc_machdep.h>
#else
#include <machine/pc/display.h>
#endif
#include <dev/syscons/syscons.h>
Move libteken out of the syscons directory. I initially committed libteken to sys/dev/syscons/teken, but now that I'm working on a console driver myself, I noticed this was not a good decision. Move it to sys/teken to make it easier for other drivers to use a terminal emulator. Also list teken.c in sys/conf/files, instead of listing it in all the files.arch files separately.
2009-09-03 09:33:57 +00:00
#include <teken/teken.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 void scteken_revattr(unsigned char, teken_attr_t *);
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
static unsigned int scteken_attr(const teken_attr_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
static sc_term_init_t scteken_init;
static sc_term_term_t scteken_term;
static sc_term_puts_t scteken_puts;
static sc_term_ioctl_t scteken_ioctl;
static sc_term_default_attr_t scteken_default_attr;
static sc_term_clear_t scteken_clear;
static sc_term_input_t scteken_input;
static void scteken_nop(void);
typedef struct {
teken_t ts_teken;
int ts_busy;
} teken_stat;
static teken_stat reserved_teken_stat;
static sc_term_sw_t sc_term_scteken = {
{ NULL, NULL },
"scteken", /* emulator name */
"teken terminal", /* description */
"*", /* matching renderer */
sizeof(teken_stat), /* softc size */
0,
scteken_init,
scteken_term,
scteken_puts,
scteken_ioctl,
(sc_term_reset_t *)scteken_nop,
scteken_default_attr,
scteken_clear,
(sc_term_notify_t *)scteken_nop,
scteken_input,
};
SCTERM_MODULE(scteken, sc_term_scteken);
static tf_bell_t scteken_bell;
static tf_cursor_t scteken_cursor;
static tf_putchar_t scteken_putchar;
static tf_fill_t scteken_fill;
static tf_copy_t scteken_copy;
static tf_param_t scteken_param;
static tf_respond_t scteken_respond;
static const teken_funcs_t scteken_funcs = {
.tf_bell = scteken_bell,
.tf_cursor = scteken_cursor,
.tf_putchar = scteken_putchar,
.tf_fill = scteken_fill,
.tf_copy = scteken_copy,
.tf_param = scteken_param,
.tf_respond = scteken_respond,
};
static int
scteken_init(scr_stat *scp, void **softc, int code)
{
Remove unneeded variable assignment. The ts variable is always initialized a few lines below. Found by: LLVM scan-build
2009-02-26 12:02:38 +00:00
teken_stat *ts;
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_pos_t tp;
if (*softc == NULL) {
if (reserved_teken_stat.ts_busy)
return (EINVAL);
*softc = &reserved_teken_stat;
}
ts = *softc;
switch (code) {
case SC_TE_COLD_INIT:
++sc_term_scteken.te_refcount;
ts->ts_busy = 1;
/* FALLTHROUGH */
case SC_TE_WARM_INIT:
teken_init(&ts->ts_teken, &scteken_funcs, scp);
Make 8-bit support run-time configurable. Now to do the same for xterm support. This means people can eventually toy around with xterm+UTF-8 without recompiling their kernel.
2009-09-12 10:34:34 +00:00
#ifndef TEKEN_UTF8
teken_set_8bit(&ts->ts_teken);
#endif /* !TEKEN_UTF8 */
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
tp.tp_row = scp->ysize;
tp.tp_col = scp->xsize;
teken_set_winsize(&ts->ts_teken, &tp);
tp.tp_row = scp->cursor_pos / scp->xsize;
tp.tp_col = scp->cursor_pos % scp->xsize;
teken_set_cursor(&ts->ts_teken, &tp);
break;
}
return (0);
}
static int
scteken_term(scr_stat *scp, void **softc)
{
if (*softc == &reserved_teken_stat) {
*softc = NULL;
reserved_teken_stat.ts_busy = 0;
}
--sc_term_scteken.te_refcount;
return (0);
}
static void
Make a 1:1 mapping between syscons stats and terminal emulators. After I imported libteken into the source tree, I noticed syscons didn't store the cursor position inside the terminal emulator, but inside the virtual terminal stat. This is not very useful, because when you implement more complex forms of line wrapping, you need to keep track of more state than just the cursor position. Because the kernel messages didn't share the same terminal emulator as ttyv0, this caused a lot of strange things, like kernel messages being misplaced and a missing notification to resize the terminal emulator for kernel messages never to be resized when using vidcontrol. This patch just removes kernel_console_ts and adds a special parameter to te_puts to determine whether messages should be printed using regular colors or the ones for kernel messages. Reported by: ache Tested by: nyan, garga (older version)
2009-03-10 11:28:54 +00:00
scteken_puts(scr_stat *scp, u_char *buf, int len, int kernel)
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_stat *ts = scp->ts;
Make a 1:1 mapping between syscons stats and terminal emulators. After I imported libteken into the source tree, I noticed syscons didn't store the cursor position inside the terminal emulator, but inside the virtual terminal stat. This is not very useful, because when you implement more complex forms of line wrapping, you need to keep track of more state than just the cursor position. Because the kernel messages didn't share the same terminal emulator as ttyv0, this caused a lot of strange things, like kernel messages being misplaced and a missing notification to resize the terminal emulator for kernel messages never to be resized when using vidcontrol. This patch just removes kernel_console_ts and adds a special parameter to te_puts to determine whether messages should be printed using regular colors or the ones for kernel messages. Reported by: ache Tested by: nyan, garga (older version)
2009-03-10 11:28:54 +00:00
teken_attr_t backup, kattr;
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
scp->sc->write_in_progress++;
Make a 1:1 mapping between syscons stats and terminal emulators. After I imported libteken into the source tree, I noticed syscons didn't store the cursor position inside the terminal emulator, but inside the virtual terminal stat. This is not very useful, because when you implement more complex forms of line wrapping, you need to keep track of more state than just the cursor position. Because the kernel messages didn't share the same terminal emulator as ttyv0, this caused a lot of strange things, like kernel messages being misplaced and a missing notification to resize the terminal emulator for kernel messages never to be resized when using vidcontrol. This patch just removes kernel_console_ts and adds a special parameter to te_puts to determine whether messages should be printed using regular colors or the ones for kernel messages. Reported by: ache Tested by: nyan, garga (older version)
2009-03-10 11:28:54 +00:00
if (kernel) {
/* Use special colors for kernel messages. */
backup = *teken_get_curattr(&ts->ts_teken);
scteken_revattr(SC_KERNEL_CONS_ATTR, &kattr);
teken_set_curattr(&ts->ts_teken, &kattr);
teken_input(&ts->ts_teken, buf, len);
teken_set_curattr(&ts->ts_teken, &backup);
} else {
/* Print user messages with regular colors. */
teken_input(&ts->ts_teken, buf, 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
scp->sc->write_in_progress--;
}
static int
scteken_ioctl(scr_stat *scp, struct tty *tp, u_long cmd, caddr_t data,
struct thread *td)
{
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
teken_stat *ts = scp->ts;
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
vid_info_t *vi;
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
unsigned int attr;
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 (cmd) {
case GIO_ATTR: /* get current attributes */
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
*(int*)data =
scteken_attr(teken_get_curattr(&ts->ts_teken));
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 (0);
case CONS_GETINFO: /* get current (virtual) console info */
vi = (vid_info_t *)data;
if (vi->size != sizeof(struct vid_info))
return EINVAL;
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
attr = scteken_attr(teken_get_defattr(&ts->ts_teken));
vi->mv_norm.fore = attr & 0x0f;
vi->mv_norm.back = (attr >> 4) & 0x0f;
vi->mv_rev.fore = vi->mv_norm.back;
vi->mv_rev.back = vi->mv_norm.fore;
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
/*
* The other fields are filled by the upper routine. XXX
*/
return (ENOIOCTL);
}
return (ENOIOCTL);
}
static void
scteken_default_attr(scr_stat *scp, int color, int rev_color)
{
teken_stat *ts = scp->ts;
teken_attr_t ta;
scteken_revattr(color, &ta);
teken_set_defattr(&ts->ts_teken, &ta);
}
static void
scteken_clear(scr_stat *scp)
{
sc_move_cursor(scp, 0, 0);
sc_vtb_clear(&scp->vtb, scp->sc->scr_map[0x20], SC_NORM_ATTR << 8);
mark_all(scp);
}
static int
scteken_input(scr_stat *scp, int c, struct tty *tp)
{
return FALSE;
}
static void
scteken_nop(void)
{
}
/*
* libteken routines.
*/
static const unsigned char fgcolors_normal[TC_NCOLORS] = {
FG_BLACK, FG_RED, FG_GREEN, FG_BROWN,
FG_BLUE, FG_MAGENTA, FG_CYAN, FG_LIGHTGREY,
};
static const unsigned char fgcolors_bold[TC_NCOLORS] = {
FG_DARKGREY, FG_LIGHTRED, FG_LIGHTGREEN, FG_YELLOW,
FG_LIGHTBLUE, FG_LIGHTMAGENTA, FG_LIGHTCYAN, FG_WHITE,
};
static const unsigned char bgcolors[TC_NCOLORS] = {
BG_BLACK, BG_RED, BG_GREEN, BG_BROWN,
BG_BLUE, BG_MAGENTA, BG_CYAN, BG_LIGHTGREY,
};
static void
scteken_revattr(unsigned char color, teken_attr_t *a)
{
teken_color_t fg, bg;
/*
* XXX: Reverse conversion of syscons to teken attributes. Not
* realiable. Maybe we should turn it into a 1:1 mapping one of
* these days?
*/
a->ta_format = 0;
a->ta_fgcolor = TC_WHITE;
a->ta_bgcolor = TC_BLACK;
#ifdef FG_BLINK
if (color & FG_BLINK) {
a->ta_format |= TF_BLINK;
color &= ~FG_BLINK;
}
#endif /* FG_BLINK */
for (fg = 0; fg < TC_NCOLORS; fg++) {
for (bg = 0; bg < TC_NCOLORS; bg++) {
if ((fgcolors_normal[fg] | bgcolors[bg]) == color) {
a->ta_fgcolor = fg;
a->ta_bgcolor = bg;
return;
}
if ((fgcolors_bold[fg] | bgcolors[bg]) == color) {
a->ta_fgcolor = fg;
a->ta_bgcolor = bg;
a->ta_format |= TF_BOLD;
return;
}
}
}
}
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
static unsigned int
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
scteken_attr(const teken_attr_t *a)
{
unsigned int attr = 0;
Expose the TF_REVERSE flag to the console driver. Right now libteken processes TF_REVERSE internally and returns the toggled colors to the console driver. This isn't entirely correct. This means that the bold flag is always processed by the foreground color, while reversing should be done after the foreground color has been set to a brighter version by the bold flag. This is no problem with the syscons driver, because with VGA it only supports 16 foreground and 8 background colors. My WIP console driver reconfigures the graphics hardware to disable the blink functionality and uses 16 foreground and 16 background colors. This means that this driver will handle the TF_REVERSE flag a little different from what syscons does right now.
2009-09-03 16:31:11 +00:00
teken_color_t fg, bg;
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
Expose the TF_REVERSE flag to the console driver. Right now libteken processes TF_REVERSE internally and returns the toggled colors to the console driver. This isn't entirely correct. This means that the bold flag is always processed by the foreground color, while reversing should be done after the foreground color has been set to a brighter version by the bold flag. This is no problem with the syscons driver, because with VGA it only supports 16 foreground and 8 background colors. My WIP console driver reconfigures the graphics hardware to disable the blink functionality and uses 16 foreground and 16 background colors. This means that this driver will handle the TF_REVERSE flag a little different from what syscons does right now.
2009-09-03 16:31:11 +00:00
if (a->ta_format & TF_REVERSE) {
fg = a->ta_bgcolor;
bg = a->ta_fgcolor;
} else {
fg = a->ta_fgcolor;
bg = a->ta_bgcolor;
}
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
if (a->ta_format & TF_BOLD)
Expose the TF_REVERSE flag to the console driver. Right now libteken processes TF_REVERSE internally and returns the toggled colors to the console driver. This isn't entirely correct. This means that the bold flag is always processed by the foreground color, while reversing should be done after the foreground color has been set to a brighter version by the bold flag. This is no problem with the syscons driver, because with VGA it only supports 16 foreground and 8 background colors. My WIP console driver reconfigures the graphics hardware to disable the blink functionality and uses 16 foreground and 16 background colors. This means that this driver will handle the TF_REVERSE flag a little different from what syscons does right now.
2009-09-03 16:31:11 +00:00
attr |= fgcolors_bold[fg];
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
else
Expose the TF_REVERSE flag to the console driver. Right now libteken processes TF_REVERSE internally and returns the toggled colors to the console driver. This isn't entirely correct. This means that the bold flag is always processed by the foreground color, while reversing should be done after the foreground color has been set to a brighter version by the bold flag. This is no problem with the syscons driver, because with VGA it only supports 16 foreground and 8 background colors. My WIP console driver reconfigures the graphics hardware to disable the blink functionality and uses 16 foreground and 16 background colors. This means that this driver will handle the TF_REVERSE flag a little different from what syscons does right now.
2009-09-03 16:31:11 +00:00
attr |= fgcolors_normal[fg];
attr |= bgcolors[bg];
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
#ifdef FG_UNDERLINE
if (a->ta_format & TF_UNDERLINE)
attr |= FG_UNDERLINE;
#endif /* FG_UNDERLINE */
#ifdef FG_BLINK
if (a->ta_format & TF_BLINK)
attr |= FG_BLINK;
#endif /* FG_BLINK */
Properly implement GIO_ATTR and CONS_GETINFO. It seems I didn't implement these two ioctl()'s properly, which meant vidcontrol couldn't properly obtain certain terminal parameters.
2009-02-09 15:55:21 +00:00
return (attr);
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
}
static void
scteken_bell(void *arg)
{
scr_stat *scp = arg;
sc_bell(scp, scp->bell_pitch, scp->bell_duration);
}
static void
scteken_cursor(void *arg, const teken_pos_t *p)
{
scr_stat *scp = arg;
sc_move_cursor(scp, p->tp_col, p->tp_row);
}
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
#ifdef TEKEN_UTF8
struct unicp437 {
uint16_t unicode_base;
uint8_t cp437_base;
uint8_t length;
};
static const struct unicp437 cp437table[] = {
Small fixes to Unicode handling: - Add more mappings for Greek characters and the Euro sign. - Print UTF-8 characters in the log file as hexadecimal.
2009-06-16 14:55:13 +00:00
{ 0x0020, 0x20, 0x5e }, { 0x00a0, 0x20, 0x00 },
{ 0x00a1, 0xad, 0x00 }, { 0x00a2, 0x9b, 0x00 },
{ 0x00a3, 0x9c, 0x00 }, { 0x00a5, 0x9d, 0x00 },
{ 0x00a7, 0x15, 0x00 }, { 0x00aa, 0xa6, 0x00 },
{ 0x00ab, 0xae, 0x00 }, { 0x00ac, 0xaa, 0x00 },
{ 0x00b0, 0xf8, 0x00 }, { 0x00b1, 0xf1, 0x00 },
{ 0x00b2, 0xfd, 0x00 }, { 0x00b5, 0xe6, 0x00 },
{ 0x00b6, 0x14, 0x00 }, { 0x00b7, 0xfa, 0x00 },
{ 0x00ba, 0xa7, 0x00 }, { 0x00bb, 0xaf, 0x00 },
{ 0x00bc, 0xac, 0x00 }, { 0x00bd, 0xab, 0x00 },
{ 0x00bf, 0xa8, 0x00 }, { 0x00c4, 0x8e, 0x01 },
{ 0x00c6, 0x92, 0x00 }, { 0x00c7, 0x80, 0x00 },
{ 0x00c9, 0x90, 0x00 }, { 0x00d1, 0xa5, 0x00 },
{ 0x00d6, 0x99, 0x00 }, { 0x00dc, 0x9a, 0x00 },
{ 0x00df, 0xe1, 0x00 }, { 0x00e0, 0x85, 0x00 },
{ 0x00e1, 0xa0, 0x00 }, { 0x00e2, 0x83, 0x00 },
{ 0x00e4, 0x84, 0x00 }, { 0x00e5, 0x86, 0x00 },
{ 0x00e6, 0x91, 0x00 }, { 0x00e7, 0x87, 0x00 },
{ 0x00e8, 0x8a, 0x00 }, { 0x00e9, 0x82, 0x00 },
{ 0x00ea, 0x88, 0x01 }, { 0x00ec, 0x8d, 0x00 },
{ 0x00ed, 0xa1, 0x00 }, { 0x00ee, 0x8c, 0x00 },
{ 0x00ef, 0x8b, 0x00 }, { 0x00f0, 0xeb, 0x00 },
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
{ 0x00f1, 0xa4, 0x00 }, { 0x00f2, 0x95, 0x00 },
{ 0x00f3, 0xa2, 0x00 }, { 0x00f4, 0x93, 0x00 },
{ 0x00f6, 0x94, 0x00 }, { 0x00f7, 0xf6, 0x00 },
Small fixes to Unicode handling: - Add more mappings for Greek characters and the Euro sign. - Print UTF-8 characters in the log file as hexadecimal.
2009-06-16 14:55:13 +00:00
{ 0x00f8, 0xed, 0x00 }, { 0x00f9, 0x97, 0x00 },
{ 0x00fa, 0xa3, 0x00 }, { 0x00fb, 0x96, 0x00 },
{ 0x00fc, 0x81, 0x00 }, { 0x00ff, 0x98, 0x00 },
{ 0x0192, 0x9f, 0x00 }, { 0x0393, 0xe2, 0x00 },
{ 0x0398, 0xe9, 0x00 }, { 0x03a3, 0xe4, 0x00 },
{ 0x03a6, 0xe8, 0x00 }, { 0x03a9, 0xea, 0x00 },
{ 0x03b1, 0xe0, 0x01 }, { 0x03b4, 0xeb, 0x00 },
{ 0x03b5, 0xee, 0x00 }, { 0x03bc, 0xe6, 0x00 },
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
{ 0x03c0, 0xe3, 0x00 }, { 0x03c3, 0xe5, 0x00 },
{ 0x03c4, 0xe7, 0x00 }, { 0x03c6, 0xed, 0x00 },
Small fixes to Unicode handling: - Add more mappings for Greek characters and the Euro sign. - Print UTF-8 characters in the log file as hexadecimal.
2009-06-16 14:55:13 +00:00
{ 0x03d5, 0xed, 0x00 }, { 0x2010, 0x2d, 0x00 },
{ 0x2014, 0x2d, 0x00 }, { 0x2018, 0x60, 0x00 },
{ 0x2019, 0x27, 0x00 }, { 0x201c, 0x22, 0x00 },
{ 0x201d, 0x22, 0x00 }, { 0x2022, 0x07, 0x00 },
{ 0x203c, 0x13, 0x00 }, { 0x207f, 0xfc, 0x00 },
{ 0x20a7, 0x9e, 0x00 }, { 0x20ac, 0xee, 0x00 },
{ 0x2126, 0xea, 0x00 }, { 0x2190, 0x1b, 0x00 },
{ 0x2191, 0x18, 0x00 }, { 0x2192, 0x1a, 0x00 },
{ 0x2193, 0x19, 0x00 }, { 0x2194, 0x1d, 0x00 },
{ 0x2195, 0x12, 0x00 }, { 0x21a8, 0x17, 0x00 },
{ 0x2202, 0xeb, 0x00 }, { 0x2208, 0xee, 0x00 },
{ 0x2211, 0xe4, 0x00 }, { 0x2212, 0x2d, 0x00 },
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
{ 0x2219, 0xf9, 0x00 }, { 0x221a, 0xfb, 0x00 },
{ 0x221e, 0xec, 0x00 }, { 0x221f, 0x1c, 0x00 },
{ 0x2229, 0xef, 0x00 }, { 0x2248, 0xf7, 0x00 },
{ 0x2261, 0xf0, 0x00 }, { 0x2264, 0xf3, 0x00 },
{ 0x2265, 0xf2, 0x00 }, { 0x2302, 0x7f, 0x00 },
{ 0x2310, 0xa9, 0x00 }, { 0x2320, 0xf4, 0x00 },
{ 0x2321, 0xf5, 0x00 }, { 0x2500, 0xc4, 0x00 },
{ 0x2502, 0xb3, 0x00 }, { 0x250c, 0xda, 0x00 },
{ 0x2510, 0xbf, 0x00 }, { 0x2514, 0xc0, 0x00 },
{ 0x2518, 0xd9, 0x00 }, { 0x251c, 0xc3, 0x00 },
{ 0x2524, 0xb4, 0x00 }, { 0x252c, 0xc2, 0x00 },
{ 0x2534, 0xc1, 0x00 }, { 0x253c, 0xc5, 0x00 },
{ 0x2550, 0xcd, 0x00 }, { 0x2551, 0xba, 0x00 },
{ 0x2552, 0xd5, 0x00 }, { 0x2553, 0xd6, 0x00 },
{ 0x2554, 0xc9, 0x00 }, { 0x2555, 0xb8, 0x00 },
{ 0x2556, 0xb7, 0x00 }, { 0x2557, 0xbb, 0x00 },
{ 0x2558, 0xd4, 0x00 }, { 0x2559, 0xd3, 0x00 },
{ 0x255a, 0xc8, 0x00 }, { 0x255b, 0xbe, 0x00 },
{ 0x255c, 0xbd, 0x00 }, { 0x255d, 0xbc, 0x00 },
{ 0x255e, 0xc6, 0x01 }, { 0x2560, 0xcc, 0x00 },
{ 0x2561, 0xb5, 0x00 }, { 0x2562, 0xb6, 0x00 },
{ 0x2563, 0xb9, 0x00 }, { 0x2564, 0xd1, 0x01 },
{ 0x2566, 0xcb, 0x00 }, { 0x2567, 0xcf, 0x00 },
{ 0x2568, 0xd0, 0x00 }, { 0x2569, 0xca, 0x00 },
{ 0x256a, 0xd8, 0x00 }, { 0x256b, 0xd7, 0x00 },
{ 0x256c, 0xce, 0x00 }, { 0x2580, 0xdf, 0x00 },
{ 0x2584, 0xdc, 0x00 }, { 0x2588, 0xdb, 0x00 },
{ 0x258c, 0xdd, 0x00 }, { 0x2590, 0xde, 0x00 },
{ 0x2591, 0xb0, 0x02 }, { 0x25a0, 0xfe, 0x00 },
{ 0x25ac, 0x16, 0x00 }, { 0x25b2, 0x1e, 0x00 },
{ 0x25ba, 0x10, 0x00 }, { 0x25bc, 0x1f, 0x00 },
Add more entries to the Unicode-to-CP437 table. Characters between 0x07 and 0x0d are now also mapped, which means we can display almost 256 different characters. Also remap certain types of dashes and quotes, which means we can finally read our manual pages without red question marks in them. Submitted by: Christoph Mallon
2009-06-14 12:04:34 +00:00
{ 0x25c4, 0x11, 0x00 }, { 0x25cb, 0x09, 0x00 },
{ 0x25d8, 0x08, 0x00 }, { 0x25d9, 0x0a, 0x00 },
{ 0x263a, 0x01, 0x01 }, { 0x263c, 0x0f, 0x00 },
{ 0x2640, 0x0c, 0x00 }, { 0x2642, 0x0b, 0x00 },
{ 0x2660, 0x06, 0x00 }, { 0x2663, 0x05, 0x00 },
{ 0x2665, 0x03, 0x01 }, { 0x266a, 0x0d, 0x01 },
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
};
static void
scteken_get_cp437(teken_char_t *c, int *attr)
{
int min, mid, max;
min = 0;
max = (sizeof(cp437table) / sizeof(struct unicp437)) - 1;
if (*c < cp437table[0].unicode_base ||
*c > cp437table[max].unicode_base + cp437table[max].length)
goto bad;
while (max >= min) {
mid = (min + max) / 2;
if (*c < cp437table[mid].unicode_base) {
max = mid - 1;
} else if (*c > cp437table[mid].unicode_base +
cp437table[mid].length) {
min = mid + 1;
} else {
*c -= cp437table[mid].unicode_base;
*c += cp437table[mid].cp437_base;
return;
}
}
bad:
/* Character not present in CP437. */
*attr = (FG_RED|BG_BLACK) << 8;
*c = '?';
}
#endif /* TEKEN_UTF8 */
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
static void
scteken_putchar(void *arg, const teken_pos_t *tp, teken_char_t c,
const teken_attr_t *a)
{
scr_stat *scp = arg;
u_char *map;
u_char ch;
vm_offset_t p;
int cursor, attr;
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
attr = scteken_attr(a) << 8;
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
#ifdef TEKEN_UTF8
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
scteken_get_cp437(&c, &attr);
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
#endif /* TEKEN_UTF8 */
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
ch = 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
map = scp->sc->scr_map;
cursor = tp->tp_row * scp->xsize + tp->tp_col;
p = sc_vtb_pointer(&scp->vtb, cursor);
sc_vtb_putchar(&scp->vtb, p, map[ch], attr);
mark_for_update(scp, cursor);
/*
* XXX: Why do we need this? Only marking `cursor' should be
* enough. Without this line, we get artifacts.
*/
mark_for_update(scp, imin(cursor + 1, scp->xsize * scp->ysize - 1));
}
static void
scteken_fill(void *arg, const teken_rect_t *r, teken_char_t c,
const teken_attr_t *a)
{
scr_stat *scp = arg;
u_char *map;
u_char ch;
unsigned int width;
int attr, row;
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
attr = scteken_attr(a) << 8;
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
#ifdef TEKEN_UTF8
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
scteken_get_cp437(&c, &attr);
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
#endif /* TEKEN_UTF8 */
Make the proof-of-concept UTF-8 support in Syscons less useless. Add a small Unicode-to-CP437 remapping table to at least demonstrate that the terminal emulator is perfectly capable of handling UTF-8. This will of course break if the user loads a different font map, but it at least allows people to give it a try. I can now see the box drawing in dialog(1) and the arrows in mutt(1) correctly.
2009-06-13 12:23:31 +00:00
ch = 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
map = scp->sc->scr_map;
if (r->tr_begin.tp_col == 0 && r->tr_end.tp_col == scp->xsize) {
/* Single contiguous region to fill. */
sc_vtb_erase(&scp->vtb, r->tr_begin.tp_row * scp->xsize,
(r->tr_end.tp_row - r->tr_begin.tp_row) * scp->xsize,
map[ch], attr);
} else {
/* Fill display line by line. */
width = r->tr_end.tp_col - r->tr_begin.tp_col;
for (row = r->tr_begin.tp_row; row < r->tr_end.tp_row; row++) {
sc_vtb_erase(&scp->vtb, r->tr_begin.tp_row *
scp->xsize + r->tr_begin.tp_col,
width, map[ch], attr);
}
}
/* Mark begin and end positions to be refreshed. */
mark_for_update(scp,
r->tr_begin.tp_row * scp->xsize + r->tr_begin.tp_col);
mark_for_update(scp,
(r->tr_end.tp_row - 1) * scp->xsize + (r->tr_end.tp_col - 1));
sc_remove_cutmarking(scp);
}
static void
scteken_copy(void *arg, const teken_rect_t *r, const teken_pos_t *p)
{
scr_stat *scp = arg;
unsigned int width;
int src, dst, end;
#ifndef SC_NO_HISTORY
/*
* We count a line of input as history if we perform a copy of
* one whole line upward. In other words: if a line of text gets
* overwritten by a rectangle that's right below it.
*/
if (scp->history != NULL &&
r->tr_begin.tp_col == 0 && r->tr_end.tp_col == scp->xsize &&
r->tr_begin.tp_row == p->tp_row + 1) {
sc_hist_save_one_line(scp, p->tp_row);
}
#endif
if (r->tr_begin.tp_col == 0 && r->tr_end.tp_col == scp->xsize) {
/* Single contiguous region to copy. */
sc_vtb_move(&scp->vtb, r->tr_begin.tp_row * scp->xsize,
p->tp_row * scp->xsize,
(r->tr_end.tp_row - r->tr_begin.tp_row) * scp->xsize);
} else {
/* Copy line by line. */
width = r->tr_end.tp_col - r->tr_begin.tp_col;
if (p->tp_row < r->tr_begin.tp_row) {
/* Copy from top to bottom. */
src = r->tr_begin.tp_row * scp->xsize +
r->tr_begin.tp_col;
end = r->tr_end.tp_row * scp->xsize +
r->tr_end.tp_col;
dst = p->tp_row * scp->xsize + p->tp_col;
while (src < end) {
sc_vtb_move(&scp->vtb, src, dst, width);
src += scp->xsize;
dst += scp->xsize;
}
} else {
/* Copy from bottom to top. */
src = (r->tr_end.tp_row - 1) * scp->xsize +
r->tr_begin.tp_col;
end = r->tr_begin.tp_row * scp->xsize +
r->tr_begin.tp_col;
dst = (p->tp_row + r->tr_end.tp_row -
r->tr_begin.tp_row - 1) * scp->xsize + p->tp_col;
while (src >= end) {
sc_vtb_move(&scp->vtb, src, dst, width);
src -= scp->xsize;
dst -= scp->xsize;
}
}
}
/* Mark begin and end positions to be refreshed. */
mark_for_update(scp,
p->tp_row * scp->xsize + p->tp_col);
mark_for_update(scp,
(p->tp_row + r->tr_end.tp_row - r->tr_begin.tp_row - 1) *
scp->xsize +
(p->tp_col + r->tr_end.tp_col - r->tr_begin.tp_col - 1));
sc_remove_cutmarking(scp);
}
static void
Restore support for bell pitch/duration. Because we only support a single argument to tf_param, use 16 bits for the pitch and 16 bits for the duration. While there, make the argument unsigned. There isn't a single param call that needs a signed integer. Submitted by: danfe (modified)
2009-05-31 19:35:41 +00:00
scteken_param(void *arg, 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
{
scr_stat *scp = arg;
switch (cmd) {
case TP_SHOWCURSOR:
if (value) {
sc_change_cursor_shape(scp,
CONS_RESET_CURSOR|CONS_LOCAL_CURSOR, -1, -1);
} else {
sc_change_cursor_shape(scp,
CONS_HIDDEN_CURSOR|CONS_LOCAL_CURSOR, -1, -1);
}
break;
case TP_SWITCHVT:
sc_switch_scr(scp->sc, value);
break;
Restore support for bell pitch/duration. Because we only support a single argument to tf_param, use 16 bits for the pitch and 16 bits for the duration. While there, make the argument unsigned. There isn't a single param call that needs a signed integer. Submitted by: danfe (modified)
2009-05-31 19:35:41 +00:00
case TP_SETBELLPD:
scp->bell_pitch = TP_SETBELLPD_PITCH(value);
scp->bell_duration = TP_SETBELLPD_DURATION(value);
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
}
}
static void
scteken_respond(void *arg, const void *buf, size_t len)
{
scr_stat *scp = arg;
sc_respond(scp, buf, len);
}
Reference in New Issue Copy Permalink