VT100/xterm-support for syscons(4) committed to SVN

From: Ed Schouten <ed_at_80386.nl>
Date: Thu, 1 Jan 2009 14:33:40 +0100
Hello all,

I've just committed libteken (the VT100/xterm-compatible terminal
emulator I've been working on) to the FreeBSD SVN source tree. See the
commit message below.

Even though I had some people test the code, there's always a chance I
did something wrong. Let me know if you discover any rendering issues.
Happy 2009!

-- 
 Ed Schouten <ed_at_80386.nl>
 WWW: http://80386.nl/

----- Forwarded message from Ed Schouten <ed_at_FreeBSD.org> -----
> Date: Thu, 1 Jan 2009 13:26:53 +0000 (UTC)
> From: Ed Schouten <ed_at_FreeBSD.org>
> To: src-committers_at_freebsd.org, svn-src-all_at_freebsd.org,
> 	svn-src-head_at_freebsd.org
> Subject: svn commit: r186681 - in head/sys: conf dev/syscons
> 	dev/syscons/teken pc98/cbus
> 
> Author: ed
> Date: Thu Jan  1 13:26:53 2009
> New Revision: 186681
> URL: http://svn.freebsd.org/changeset/base/186681
> 
> Log:
>   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_at_, hackers_at_
>   Discussed with:	philip (at 25C3)
>
----- End forwarded message -----

Received on Thu Jan 01 2009 - 12:33:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC