d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
15b7a831df
freebsd-skq/sys/teken/teken.h

179 lines
4.9 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) 2008-2009 Ed Schouten <ed@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#ifndef _TEKEN_H_
#define _TEKEN_H_
/*
* libteken: terminal emulation library.
*
* This library converts an UTF-8 stream of bytes to terminal drawing
Allow experimental libteken features to be tested without changing code. The teken library already supports UTF-8 handling and xterm emulation, but we have reasons to disable this right now. Because we should make it easy and interesting for people to experiment with these features, allow them to be set in kernel configuration files. Before this commit we had a flag called `TEKEN_CONS25' to enable cons25-style emulation. I'm calling it the opposite now, `TEKEN_XTERM', because we want to enable it in kernel configuration files explicitly. Requested by: kib
2009-01-17 16:37:13 +00:00
* commands.
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
*/
typedef uint32_t teken_char_t;
typedef unsigned short teken_unit_t;
typedef unsigned char teken_format_t;
#define TF_BOLD 0x01
#define TF_UNDERLINE 0x02
#define TF_BLINK 0x04
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
#define TF_REVERSE 0x08
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
typedef unsigned char teken_color_t;
#define TC_BLACK 0
#define TC_RED 1
#define TC_GREEN 2
#define TC_BROWN 3
#define TC_BLUE 4
#define TC_MAGENTA 5
#define TC_CYAN 6
#define TC_WHITE 7
#define TC_NCOLORS 8
typedef struct {
teken_unit_t tp_row;
teken_unit_t tp_col;
} teken_pos_t;
typedef struct {
teken_pos_t tr_begin;
teken_pos_t tr_end;
} teken_rect_t;
typedef struct {
teken_format_t ta_format;
teken_color_t ta_fgcolor;
teken_color_t ta_bgcolor;
} teken_attr_t;
typedef struct {
teken_unit_t ts_begin;
teken_unit_t ts_end;
} teken_span_t;
typedef struct __teken teken_t;
typedef void teken_state_t(teken_t *, teken_char_t);
/*
* Drawing routines supplied by the user.
*/
typedef void tf_bell_t(void *);
typedef void tf_cursor_t(void *, const teken_pos_t *);
typedef void tf_putchar_t(void *, const teken_pos_t *, teken_char_t,
const teken_attr_t *);
typedef void tf_fill_t(void *, const teken_rect_t *, teken_char_t,
const teken_attr_t *);
typedef void tf_copy_t(void *, const teken_rect_t *, const teken_pos_t *);
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
typedef void tf_param_t(void *, int, 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
#define TP_SHOWCURSOR 0
#define TP_CURSORKEYS 1
#define TP_KEYPADAPP 2
#define TP_AUTOREPEAT 3
#define TP_SWITCHVT 4
#define TP_132COLS 5
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
#define TP_SETBELLPD 6
#define TP_SETBELLPD_PITCH(pd) ((pd) >> 16)
#define TP_SETBELLPD_DURATION(pd) ((pd) & 0xffff)
Add support for VT200-style mouse input. Right now if applications want to use the mouse on the command line, they use sysmouse(4) and install a signal handler in the kernel to deliver signals when mouse events arrive. This conflicts with my plan to change to TERM=xterm, so implement proper VT200-style mouse input. Because mouse input is now streamed through the TTY, it means you can now SSH to another system on the console and use the mouse there as well. The disadvantage of the VT200 mouse protocol, is that it doesn't seem to generate events when moving the cursor. Only when pressing and releasing mouse buttons. There are different protocols as well, but this one seems to be most commonly supported. Reported by: Paul B. Mahol <onemda gmail com> Tested with: vim(1)
2009-09-27 18:19:41 +00:00
#define TP_MOUSE 7
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
typedef void tf_respond_t(void *, const void *, size_t);
typedef struct {
tf_bell_t *tf_bell;
tf_cursor_t *tf_cursor;
tf_putchar_t *tf_putchar;
tf_fill_t *tf_fill;
tf_copy_t *tf_copy;
tf_param_t *tf_param;
tf_respond_t *tf_respond;
} teken_funcs_t;
Make SCS work in 8-bit mode. This means we can finally do things like VT100 box drawing when using Syscons (8-bit characters). As far as I know, the only remaining issue is the absense of proper escape sequences for special keyboard characters (cursor, F1 to F12, etc) and xterm emulation should be ready for general use. Enabling xterm would have the following advantages: - Easier possible migration to Unicode. cons25 termcap entries are very 8-bit centric. They use things like CP437 characters for box drawing, etc. - Better support for SSH'ing to other operating systems/devices. Most switches use VT100-style admin interfaces. - Reduced bandwidth, because applications can now use things like scrolling regions. - You can finally use applications like dtach(1) on both the console and inside an xterm.
2009-09-24 20:33:14 +00:00
typedef teken_char_t teken_scs_t(teken_t *, teken_char_t);
Properly implement the VT100 SCS sequences in xterm-mode. Even though VT100-like devices can display non-ASCII characters, they do not use an 8-bit character set. Special escape sequences allow the VT100 to switch character maps. The special graphics character set stores the box drawing characters, starting at 0x60, ending at 0x7e. This means we now pass the character map tests in vttest, even the save/restore cursor test, combined with character maps. dialog(1) also works a lot better now. This commit also includes some other minor fixes: - Default to 24 lines in teken_demo when using xterm emulation. - Make white foreground and background work in teken_demo.
2009-01-20 11:34:28 +00:00
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
/*
* Terminal state.
*/
struct __teken {
const teken_funcs_t *t_funcs;
void *t_softc;
teken_state_t *t_nextstate;
unsigned int t_stateflags;
#define T_NUMSIZE 8
unsigned int t_nums[T_NUMSIZE];
unsigned int t_curnum;
teken_pos_t t_cursor;
teken_attr_t t_curattr;
teken_pos_t t_saved_cursor;
teken_attr_t t_saved_curattr;
teken_attr_t t_defattr;
teken_pos_t t_winsize;
/* For DECSTBM. */
teken_span_t t_scrollreg;
/* For DECOM. */
teken_span_t t_originreg;
#define T_NUMCOL 160
Properly implement the VT100 SCS sequences in xterm-mode. Even though VT100-like devices can display non-ASCII characters, they do not use an 8-bit character set. Special escape sequences allow the VT100 to switch character maps. The special graphics character set stores the box drawing characters, starting at 0x60, ending at 0x7e. This means we now pass the character map tests in vttest, even the save/restore cursor test, combined with character maps. dialog(1) also works a lot better now. This commit also includes some other minor fixes: - Default to 24 lines in teken_demo when using xterm emulation. - Make white foreground and background work in teken_demo.
2009-01-20 11:34:28 +00:00
unsigned int t_tabstops[T_NUMCOL / (sizeof(unsigned int) * 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
Commit all local modifications I have to libteken: - Make xterm/cons25 support runtime configurable. This allows me to share libteken between syscons and my new vt driver. - Add a fix to print blanks after printing a double width character to prevent rendering artifacts. - Add some more utility functions that I use in the vt driver.
2009-09-12 12:44:21 +00:00
unsigned int t_utf8_left;
Properly implement the VT100 SCS sequences in xterm-mode. Even though VT100-like devices can display non-ASCII characters, they do not use an 8-bit character set. Special escape sequences allow the VT100 to switch character maps. The special graphics character set stores the box drawing characters, starting at 0x60, ending at 0x7e. This means we now pass the character map tests in vttest, even the save/restore cursor test, combined with character maps. dialog(1) also works a lot better now. This commit also includes some other minor fixes: - Default to 24 lines in teken_demo when using xterm emulation. - Make white foreground and background work in teken_demo.
2009-01-20 11:34:28 +00:00
teken_char_t t_utf8_partial;
unsigned int t_curscs;
teken_scs_t *t_saved_curscs;
teken_scs_t *t_scs[2];
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
};
/* Initialize teken structure. */
void teken_init(teken_t *, const teken_funcs_t *, void *);
/* Deliver character input. */
void teken_input(teken_t *, const void *, size_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
/* Get/set teken attributes. */
Commit all local modifications I have to libteken: - Make xterm/cons25 support runtime configurable. This allows me to share libteken between syscons and my new vt driver. - Add a fix to print blanks after printing a double width character to prevent rendering artifacts. - Add some more utility functions that I use in the vt driver.
2009-09-12 12:44:21 +00:00
const teken_pos_t *teken_get_cursor(teken_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
const teken_attr_t *teken_get_curattr(teken_t *);
const teken_attr_t *teken_get_defattr(teken_t *);
Commit all local modifications I have to libteken: - Make xterm/cons25 support runtime configurable. This allows me to share libteken between syscons and my new vt driver. - Add a fix to print blanks after printing a double width character to prevent rendering artifacts. - Add some more utility functions that I use in the vt driver.
2009-09-12 12:44:21 +00:00
void teken_get_defattr_cons25(teken_t *, int *, int *);
const teken_pos_t *teken_get_winsize(teken_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
void teken_set_cursor(teken_t *, const teken_pos_t *);
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
void teken_set_curattr(teken_t *, 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
void teken_set_defattr(teken_t *, const teken_attr_t *);
void teken_set_winsize(teken_t *, const teken_pos_t *);
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
/* Legacy features. */
void teken_set_8bit(teken_t *);
Commit all local modifications I have to libteken: - Make xterm/cons25 support runtime configurable. This allows me to share libteken between syscons and my new vt driver. - Add a fix to print blanks after printing a double width character to prevent rendering artifacts. - Add some more utility functions that I use in the vt driver.
2009-09-12 12:44:21 +00:00
void teken_set_cons25(teken_t *);
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
Add 256 color support. It is quite inconvenient that if an application for xterm uses 256 color mode, text suddenly starts to blink (because of ;5; in the middle). We'd better just implement 256 color mode and add a conversion routine from 256 to 8 color mode, which doesn't seem to be too bad in practice. Remapping colors is done quite simple. If one of the channels is most actively represented, primary colors are used. If two channels are most actively represented, secondary colors are used. If all three channels are equal (gray), it picks between black and white. Reported by: Paul B. Mahol <onemda gmail com>
2009-09-26 15:26:32 +00:00
/* Color conversion. */
teken_color_t teken_256to8(teken_color_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
#endif /* !_TEKEN_H_ */
Reference in New Issue Copy Permalink