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

127 lines
3.5 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$
*/
static void
teken_subr_cons25_set_cursor_type(teken_t *t, unsigned int type)
{
teken_funcs_param(t, TP_SHOWCURSOR, type != 1);
}
Don't forget to mark the color translation array as const. Spotted by: Christoph Mallon <christoph mallon gmx de>
2009-01-18 09:44:33 +00:00
static const teken_color_t cons25_colors[8] = { TC_BLACK, TC_BLUE,
TC_GREEN, TC_CYAN, TC_RED, TC_MAGENTA, TC_BROWN, TC_WHITE };
Fix for my previous commit: color mapping is not 1:1. Cons25 doesn't seem to use a straight 1:1 mapping to the ANSI colors, but uses the same color numbers as at least used by syscons on i386. I suspect if you change the definitions on a different architecture, things may break? Not sure. Add a small array to convert syscons-style color codes to ANSI equivalents, which are used by libteken internally. I didn't notice this bug, because I only tested my code with black, white and green, all of them shared the same numbers.
2009-01-17 23:01:40 +00:00
Make vidcontrol's color setting work again. It turns out I forgot to implement two escape sequences that allows the user to change the default foreground and background colors. I thought they were implemented by syscons itself, but vidcontrol just generates some escape sequences, which get interpreted by the terminal emulator. Reported by: mgp (forums)
2009-01-17 22:53:53 +00:00
static void
teken_subr_cons25_set_adapter_background(teken_t *t, unsigned int c)
{
Fix for my previous commit: color mapping is not 1:1. Cons25 doesn't seem to use a straight 1:1 mapping to the ANSI colors, but uses the same color numbers as at least used by syscons on i386. I suspect if you change the definitions on a different architecture, things may break? Not sure. Add a small array to convert syscons-style color codes to ANSI equivalents, which are used by libteken internally. I didn't notice this bug, because I only tested my code with black, white and green, all of them shared the same numbers.
2009-01-17 23:01:40 +00:00
t->t_defattr.ta_bgcolor = cons25_colors[c % 8];
t->t_curattr.ta_bgcolor = cons25_colors[c % 8];
Make vidcontrol's color setting work again. It turns out I forgot to implement two escape sequences that allows the user to change the default foreground and background colors. I thought they were implemented by syscons itself, but vidcontrol just generates some escape sequences, which get interpreted by the terminal emulator. Reported by: mgp (forums)
2009-01-17 22:53:53 +00:00
}
static void
teken_subr_cons25_set_adapter_foreground(teken_t *t, unsigned int c)
{
Fix for my previous commit: color mapping is not 1:1. Cons25 doesn't seem to use a straight 1:1 mapping to the ANSI colors, but uses the same color numbers as at least used by syscons on i386. I suspect if you change the definitions on a different architecture, things may break? Not sure. Add a small array to convert syscons-style color codes to ANSI equivalents, which are used by libteken internally. I didn't notice this bug, because I only tested my code with black, white and green, all of them shared the same numbers.
2009-01-17 23:01:40 +00:00
t->t_defattr.ta_fgcolor = cons25_colors[c % 8];
t->t_curattr.ta_fgcolor = cons25_colors[c % 8];
Make vidcontrol's color setting work again. It turns out I forgot to implement two escape sequences that allows the user to change the default foreground and background colors. I thought they were implemented by syscons itself, but vidcontrol just generates some escape sequences, which get interpreted by the terminal emulator. Reported by: mgp (forums)
2009-01-17 22:53:53 +00:00
if (c >= 8) {
t->t_defattr.ta_format |= TF_BOLD;
t->t_curattr.ta_format |= TF_BOLD;
} else {
t->t_defattr.ta_format &= ~TF_BOLD;
t->t_curattr.ta_format &= ~TF_BOLD;
}
}
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
static const teken_color_t cons25_revcolors[8] = { 0, 4, 2, 6, 1, 5, 3, 7 };
void
teken_get_defattr_cons25(teken_t *t, int *fg, int *bg)
{
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
*fg = cons25_revcolors[teken_256to8(t->t_defattr.ta_fgcolor)];
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
if (t->t_defattr.ta_format & TF_BOLD)
*fg += 8;
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
*bg = cons25_revcolors[teken_256to8(t->t_defattr.ta_bgcolor)];
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
}
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
static void
teken_subr_cons25_switch_virtual_terminal(teken_t *t, unsigned int vt)
{
teken_funcs_param(t, TP_SWITCHVT, vt);
}
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
static void
teken_subr_cons25_set_bell_pitch_duration(teken_t *t, unsigned int pitch,
unsigned int duration)
{
teken_funcs_param(t, TP_SETBELLPD, (pitch << 16) |
(duration & 0xffff));
}
Partially implement the mysterious cons25 \e[x escape sequence. It seems the terminfo library on some systems (OS X, Linux) may emit the sequence \e[x to reset to default attributes. Apart from using the zero-command, this escape sequence allows many more operations, such as setting ANSI colors. I don't see this used anywhere, so this should be sufficient for now. This deficiency was spotted by the Debian GNU/kFreeBSD. They have their own patch, which is slightly flawed in my opinion. I don't know why they never reported this issue to us. MFC after: 1 week
2010-11-05 00:56:21 +00:00
static void
teken_subr_cons25_set_graphic_rendition(teken_t *t, unsigned int cmd,
unsigned int param __unused)
{
switch (cmd) {
case 0: /* Reset. */
t->t_curattr = t->t_defattr;
break;
default:
teken_printf("unsupported attribute %u\n", cmd);
}
}
Add a new escape sequence to switch between cons25 and xterm. Just run this to switch to xterm: printf '\e[=T' If you get bored and want to switch back to cons25, run this: printf '\e[=1T' I can now send an email to the lists, asking whether people are interested in trying the xterm emulator.
2009-09-25 13:51:01 +00:00
static void
teken_subr_cons25_set_terminal_mode(teken_t *t, unsigned int mode)
{
switch (mode) {
case 0: /* Switch terminal to xterm. */
t->t_stateflags &= ~TS_CONS25;
break;
case 1: /* Switch terminal to cons25. */
t->t_stateflags |= TS_CONS25;
break;
}
}
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 13:26:53 +00:00
#if 0
static void
teken_subr_vt52_decid(teken_t *t)
{
const char response[] = "\x1B/Z";
teken_funcs_respond(t, response, sizeof response - 1);
}
#endif
Reference in New Issue Copy Permalink