#
186681 |
|
01-Jan-2009 |
ed |
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)
|
#
105584 |
|
20-Oct-2002 |
robert |
Do not try to work around ``poor (un)sign extension code'' creation by GCC-2.6.3. Casting pointers to unsigned char to volatile pointers to unsigned char seemed to produce better results on the ia32 architecture with old versions of GCC. The current FreeBSD system compiler GCC-3.2.1 emits better sign extension code for non-volatile variables:
volatile char c; int i = c;
is compiled to: ... movb -1(%ebp), %al movbsl %al, %eax movl %eax, -8(%ebp) ...
char c; int i = c;
is compiled to: ... movbsl -1(%ebp), %eax movl %eax, -8(%ebp) ...
The same holds for zero-extension of dereferenced pointers to volatile unsigned char. When compiled on alpha or sparc64, the code produced for the two examples above does not differ.
|
#
56043 |
|
15-Jan-2000 |
yokota |
This is the 3rd stage of syscons code reorganization.
- Split terminal emulation code from the main part of the driver so that we can have alternative terminal emulator modules if we like in the future. (We are not quite there yet, though.)
- Put sysmouse related code in a separate file, thus, simplifying the main part of the driver.
As some files are added to the source tree, you need to run config(8) before you compile a new kernel next time.
You shouldn't see any functional change by this commit; this is only internal code reorganization.
|