Re: Making wscons a bit more like xterm
Some programs will always ignore terminfo and make their own guesses, that's just the nature of terminfo, not much to be done about it. I meant ignore bold in combination with 256 colours, not ignore it entirely. But if you can come up with some scheme to display it then go for it. If possible can you now give me your latest patches without 256 colours and I will test them and see if we can get them in. Probably best to split them into three: new escape sequences, additional key sequences, and bug fixes to existing code. On Sat, 7 Jan 2023, 12:05 Crystal Kolipe, wrote: > On Sat, Jan 07, 2023 at 11:09:00AM +, Nicholas Marriott wrote: > > As far as SGR 38/48 with anything except 2 and 5 goes - the only > terminals > > I have at hand do not discard but I think either of discarding or not > > discarding would be reasonable. What does xterm do here? It would > probably > > be best to do the same. > > Xterm only ignores the unknown argument immediately following the 38/48, > but > interprets the rest. So SGR 38;9;1m sets bold. > > I've changed my code to do the same. > > > On terminals with fewer than 256 colours, I think the sequence should > > probably do nothing. > > I've seen one program that uses it when colours <= 8, but that seems to > have > been an oversight. > > > I would be inclined to just ignore bold together with 256 colours (that > is, > > don't make bold change anything) as the terminal only supports bright and > > not true bold. > > Hummm. That would break existing behaviour in a few cases. > > Although most users are not seeing colour at all on the console, anyone who > has set TERM=pccon currently has working bold in programs that parse > terminfo. > > Also there are obviously programs that just assume ansi sequences are > recognised. Bold is such an old and basic attribute that it's pretty > reasonable to assume that it is implemented somehow on any modern terminal > that implements any ansi sequences. > > > Making an alternative colour map which is brighter would be > > possible, although I haven't seen any terminals that do that. > > That's interesting. Although it would be nicer to have a real bold font. > Maybe just printing the exising font twice, offset one pixel to the right > would work for that? > > Regarding 256 colour support in general, this is very much a late addition > to > the whole project of making the console usable with the xterm terminfo > entry. > > I'm quite enthusiastic about adding it now, but if it's going to make the > original goal of s/vt220/xterm in /etc/ttys less attractive because it > causes > breakage in obscure corner cases, then I can always drop the 256 colour > part. > > Although to be honest, I think that the rest of the patchset without the > 256 colour support is already very close to being usable. Even as it is, > it's > an overall improvement because it fixes several exising bugs. > > In any case, I'll post an updated version with 256 in an hour or so. >
Re: Making wscons a bit more like xterm
Ah, here is a trivial program to demo the new 256 color palette on the console:
#include
int main()
{
int i;
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[38;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "\n"));
}
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[48;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "[m\n"));
}
printf ("\x1b[m\n");
}
Re: Making wscons a bit more like xterm
On Sat, Jan 07, 2023 at 09:05:21AM -0300, Crystal Kolipe wrote:
> In any case, I'll post an updated version with 256 in an hour or so.
It's here!
NEW - 256 colour support! (Not extensively tested yet).
NEW - Interpret SGR 38/48 sequences instead of just discarding the following
parameters.
NEW - Implement SGR 9x and 10x sequences to select 'bright' foreground and
background colours, (I.E. colours 8 - 15), directly.
- All the features of the previous patches.
So this version is mostly to add 256 colour support. This was mainly a
consequence of needing to do something with SGR 38/48 in order to avoid
programs that use them directly setting unwanted attributes.
Resume of code changes:
* Adds a new WSSCREEN_256COL capability which is currently set for 32bpp
displays only.
* When running in 32bpp, the device colour map is re-programmed for colours
16 - 255.
* Several 4-bit fields have been expanded to 8-bit.
* Resizes ri_devcmap from 16 to 256 entries.
* Bold, which is implemented as higher intensity, is limited to the eight
'normal' colours. (This might change in a later version.)
Notes:
* Please test for regressions and breakage.
* The plain 'xterm' terminfo entry doesn't support 256 colours, so you
probably want to use TERM=xterm-256color instead.
* However testing with plain TERM=xterm is definitely still needed!
* Programs that ignore terminfo and send ansi sequences directly will also
benefit from testing.
Question:
There is a comment in rasops.c saying that the last 16 colours should be the
inverse of the first 16. However, from reading the code this seems to apply
only if we are both using a palletised display _and_ using rasops_do_cursor
instead of rasops_wronly_do_cursor.
(The comment pre-dates the addition of rasops_wronly_do_cursor by many years.)
Or have I missed something? Should I update the comment?
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select:
Re: Making wscons a bit more like xterm
On Sat, Jan 07, 2023 at 11:09:00AM +, Nicholas Marriott wrote: > As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals > I have at hand do not discard but I think either of discarding or not > discarding would be reasonable. What does xterm do here? It would probably > be best to do the same. Xterm only ignores the unknown argument immediately following the 38/48, but interprets the rest. So SGR 38;9;1m sets bold. I've changed my code to do the same. > On terminals with fewer than 256 colours, I think the sequence should > probably do nothing. I've seen one program that uses it when colours <= 8, but that seems to have been an oversight. > I would be inclined to just ignore bold together with 256 colours (that is, > don't make bold change anything) as the terminal only supports bright and > not true bold. Hummm. That would break existing behaviour in a few cases. Although most users are not seeing colour at all on the console, anyone who has set TERM=pccon currently has working bold in programs that parse terminfo. Also there are obviously programs that just assume ansi sequences are recognised. Bold is such an old and basic attribute that it's pretty reasonable to assume that it is implemented somehow on any modern terminal that implements any ansi sequences. > Making an alternative colour map which is brighter would be > possible, although I haven't seen any terminals that do that. That's interesting. Although it would be nicer to have a real bold font. Maybe just printing the exising font twice, offset one pixel to the right would work for that? Regarding 256 colour support in general, this is very much a late addition to the whole project of making the console usable with the xterm terminfo entry. I'm quite enthusiastic about adding it now, but if it's going to make the original goal of s/vt220/xterm in /etc/ttys less attractive because it causes breakage in obscure corner cases, then I can always drop the 256 colour part. Although to be honest, I think that the rest of the patchset without the 256 colour support is already very close to being usable. Even as it is, it's an overall improvement because it fixes several exising bugs. In any case, I'll post an updated version with 256 in an hour or so.
Re: Making wscons a bit more like xterm
On terminals with fewer than 256 colours, I think the sequence should probably do nothing. I would be inclined to just ignore bold together with 256 colours (that is, don't make bold change anything) as the terminal only supports bright and not true bold. Making an alternative colour map which is brighter would be possible, although I haven't seen any terminals that do that. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > > You should strictly only discard the following two arguments or stuff > like > > SGR 38;5;100;1 won't work. > > Well I was initially in two minds about that, because I thought there > might be > other un-official extensions that used 38 with a varying number of > parameters. > > But I haven't found any apart from 5 followed by one argument, and 2 > followed > by three RGB values, so yes I agree with you on this. > > However, since this morning I've been working on actually implementing 256 > colour support so the next version of the patch will parse SGR 38;5 > sequences > correctly. > > Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still > have to discard everything, right? Because that would be an invalid > sequence > and we don't know for sure whether anything that comes after it is actually > intended as regular control codes or parameters for something else. > > I.E. > > SGR 38;5;X - we set colour X. > SGR 38;2;X;X;X - we discard three parameters, then continue parsing. > SGR 38;Y; - where Y is 'something else', we ignore everything until the > 'm'. > > Or is there a better way? > > Regarding 256 colour support, I've got it working, (on 32bpp displays > only), > but there are two open questions: > > 1. On displays that don't support 256 colours, (e.g. VGA console), what > should >SGR 38;5;X do? I currently have it set so that it selects colours 0-7, > and >for 8-255 just does nothing, (leaves the current colour). > > 2. We implement bold as brighter text rather than a bold font. This > doesn't >work very well with a 256 colour palette. We can't just +8 to get a > bright >version of the colour. How should bold work with arbitrary colours? > > > This is why some people prefer the : form but the ship has rather sailed > on > > that. > > I'm assuming that we don't really need to implement the : form? > > Thanks again for the feedback. >
Re: Making wscons a bit more like xterm
IIRC xterm-direct uses the : form for RGB colour but xterm-256color does not use it for 256 colours, so for 256 colours you can no doubt get away without it. As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals I have at hand do not discard but I think either of discarding or not discarding would be reasonable. What does xterm do here? It would probably be best to do the same. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > > You should strictly only discard the following two arguments or stuff > like > > SGR 38;5;100;1 won't work. > > Well I was initially in two minds about that, because I thought there > might be > other un-official extensions that used 38 with a varying number of > parameters. > > But I haven't found any apart from 5 followed by one argument, and 2 > followed > by three RGB values, so yes I agree with you on this. > > However, since this morning I've been working on actually implementing 256 > colour support so the next version of the patch will parse SGR 38;5 > sequences > correctly. > > Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still > have to discard everything, right? Because that would be an invalid > sequence > and we don't know for sure whether anything that comes after it is actually > intended as regular control codes or parameters for something else. > > I.E. > > SGR 38;5;X - we set colour X. > SGR 38;2;X;X;X - we discard three parameters, then continue parsing. > SGR 38;Y; - where Y is 'something else', we ignore everything until the > 'm'. > > Or is there a better way? > > Regarding 256 colour support, I've got it working, (on 32bpp displays > only), > but there are two open questions: > > 1. On displays that don't support 256 colours, (e.g. VGA console), what > should >SGR 38;5;X do? I currently have it set so that it selects colours 0-7, > and >for 8-255 just does nothing, (leaves the current colour). > > 2. We implement bold as brighter text rather than a bold font. This > doesn't >work very well with a 256 colour palette. We can't just +8 to get a > bright >version of the colour. How should bold work with arbitrary colours? > > > This is why some people prefer the : form but the ship has rather sailed > on > > that. > > I'm assuming that we don't really need to implement the : form? > > Thanks again for the feedback. >
Re: Making wscons a bit more like xterm
On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > You should strictly only discard the following two arguments or stuff like > SGR 38;5;100;1 won't work. Well I was initially in two minds about that, because I thought there might be other un-official extensions that used 38 with a varying number of parameters. But I haven't found any apart from 5 followed by one argument, and 2 followed by three RGB values, so yes I agree with you on this. However, since this morning I've been working on actually implementing 256 colour support so the next version of the patch will parse SGR 38;5 sequences correctly. Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still have to discard everything, right? Because that would be an invalid sequence and we don't know for sure whether anything that comes after it is actually intended as regular control codes or parameters for something else. I.E. SGR 38;5;X - we set colour X. SGR 38;2;X;X;X - we discard three parameters, then continue parsing. SGR 38;Y; - where Y is 'something else', we ignore everything until the 'm'. Or is there a better way? Regarding 256 colour support, I've got it working, (on 32bpp displays only), but there are two open questions: 1. On displays that don't support 256 colours, (e.g. VGA console), what should SGR 38;5;X do? I currently have it set so that it selects colours 0-7, and for 8-255 just does nothing, (leaves the current colour). 2. We implement bold as brighter text rather than a bold font. This doesn't work very well with a 256 colour palette. We can't just +8 to get a bright version of the colour. How should bold work with arbitrary colours? > This is why some people prefer the : form but the ship has rather sailed on > that. I'm assuming that we don't really need to implement the : form? Thanks again for the feedback.
Re: Making wscons a bit more like xterm
You should strictly only discard the following two arguments or stuff like
SGR 38;5;100;1 won't work.
This is why some people prefer the : form but the ship has rather sailed on
that.
On Fri, 6 Jan 2023, 11:52 Crystal Kolipe,
wrote:
> This version of the patchset updates a few things since the one posted
> early
> on Wednesday:
>
> NEW - Fix two off-by-ones that caused spurious trailing null characters
> when
> requesting the terminal IDs. (Noticed by Paul running tmux.)
>
> NEW - Discard any parameters passed to a CSI 38 m or CSI 48 m sequence.
> See below for more discussion on this.
>
> NEW - Tweaked dim attribute to work correctly on byte-swapped framebuffers.
>
> * Control sequences for dim text, invisible text, strike through, italic,
> and
> double underline attributes are now recognised and set flags in wscons.
> * Rendering of dim, invisible, struck, and double underlined text is now
> supported in rasops32.c, so users of 32bpp displays will see these text
> effects on the console.
> * The default number of scrollback screens has been increased from five to
> twenty.
> * F1 - F4 and F13 - F24 now send different sequences.
> * With numlock OFF, keypad 5 is now 'begin' rather than unused.
> * Home, End, keypad home, and keypad end now send different sequences.
> * A new keysym has been added - KS_Backtab.
> * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
> * Shift-F1 - Shift-F12 now send F13 - F24.
> * Five new escape sequences added for cursor movement.
>
> Off by ones:
>
> These can actually be triggered with the existing console code, without
> even
> applying any of my patches, and stem from using sizeof with a string
> constant,
> which returns the length of the string _including_ the terminating null.
>
> CSI 38 m and CSI 48 m sequences:
>
> The 30-37 codes set one of eight fixed foreground colours, the 40-47 codes
> set
> the background in the same way. Codes 39 and 49 reset to the default
> colours.
>
> Codes 38 and 48 have become used as an escape to a larger colour space,
> typically 256 colours or 24-bit colour.
>
> A typical invocation to select colour 100 from a 256 colour palette might
> be:
>
> CSI 38;5;100m
>
> Such sequences are not defined in the terminfo entry for xterm. However,
> some
> programs use them, assuming that they are supported.
>
> The current wscons code ignores the unimplemented 38, but then proceeds to
> interpret 5 and 100 as further SGR codes.
>
> In many cases, this doesn't much of a problem, because although 5 enables
> blink, none of the rasops code supports blink anyway. However, the last
> value
> can potentially set any SGR attribute. So, for example:
>
> CSI 38;5;4m
>
> ...will not select colour 4 as the program is expecting, but instead turn
> on
> underlining.
>
> To avoid this, the lastest version of my patch simply discards all values
> after a 38 or 48, until the trailing 'm'.
>
> This works to avoid setting unwanted attributes, until such time as 256
> colour
> support is added, (if this is even desired).
>
> --- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
> +++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
> @@ -37,11 +37,9 @@
> #include
> #include
>
> +#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
> +
> static const u_char *vt100_fkeys[] = {
> - "\033[11~", /* F1 */
> - "\033[12~",
> - "\033[13~", /* F1-F5 normally don't send codes */
> - "\033[14~",
> "\033[15~", /* F5 */
> "\033[17~", /* F6 */
> "\033[18~",
> @@ -50,18 +48,18 @@
> "\033[21~",
> "\033[23~", /* VT100: ESC */
> "\033[24~", /* VT100: BS */
> - "\033[25~", /* VT100: LF */
> - "\033[26~",
> - "\033[28~", /* help */
> - "\033[29~", /* do */
> - "\033[31~",
> - "\033[32~",
> - "\033[33~",
> - "\033[34~", /* F20 */
> - "\033[35~",
> - "\033[36~",
> - "\033[37~",
> - "\033[38~"
> + "\033[1;2P",/* VT100: LF */
> + "\033[1;2Q",
> + "\033[1;2R",/* help */
> + "\033[1;2S",/* do */
> + "\033[15;2~",
> + "\033[17;2~",
> + "\033[18;2~",
> + "\033[19;2~", /* F20 */
> + "\033[20;2~",
> + "\033[21;2~",
> + "\033[23;2~",
> + "\033[24;2~"
> };
>
> static const u_char *vt100_pfkeys[] = {
> @@ -96,14 +94,22 @@
> edp->translatebuf, edp->flags & VTFL_UTF8));
> }
>
> - if (in >= KS_f1 && in <= KS_f24) {
> - *out = vt100_fkeys[in - KS_f1];
> - return (5);
> + if (in >= KS_f1 && in <= KS_f4) {
> + *out = vt100_pfkeys[in - KS_f1];
> + return (3);
> }
> - if (in >= KS_F1 && in <= KS_F24) {
> - *out = vt100_fkeys[in - KS_F1];
> - return (5);
> + if (in >= KS_F1 && in <= KS_F4) {
> + *out =
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 05:42:31PM -0300, Crystal Kolipe wrote: | Hopefully it'll fix the problem. Tested with tmux, the spurious ^@'s are now indeed gone. I see there's a new diff available, so I'll try that out in a bit. Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Making wscons a bit more like xterm
This version of the patchset updates a few things since the one posted early
on Wednesday:
NEW - Fix two off-by-ones that caused spurious trailing null characters when
requesting the terminal IDs. (Noticed by Paul running tmux.)
NEW - Discard any parameters passed to a CSI 38 m or CSI 48 m sequence.
See below for more discussion on this.
NEW - Tweaked dim attribute to work correctly on byte-swapped framebuffers.
* Control sequences for dim text, invisible text, strike through, italic, and
double underline attributes are now recognised and set flags in wscons.
* Rendering of dim, invisible, struck, and double underlined text is now
supported in rasops32.c, so users of 32bpp displays will see these text
effects on the console.
* The default number of scrollback screens has been increased from five to
twenty.
* F1 - F4 and F13 - F24 now send different sequences.
* With numlock OFF, keypad 5 is now 'begin' rather than unused.
* Home, End, keypad home, and keypad end now send different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send F13 - F24.
* Five new escape sequences added for cursor movement.
Off by ones:
These can actually be triggered with the existing console code, without even
applying any of my patches, and stem from using sizeof with a string constant,
which returns the length of the string _including_ the terminating null.
CSI 38 m and CSI 48 m sequences:
The 30-37 codes set one of eight fixed foreground colours, the 40-47 codes set
the background in the same way. Codes 39 and 49 reset to the default colours.
Codes 38 and 48 have become used as an escape to a larger colour space,
typically 256 colours or 24-bit colour.
A typical invocation to select colour 100 from a 256 colour palette might be:
CSI 38;5;100m
Such sequences are not defined in the terminfo entry for xterm. However, some
programs use them, assuming that they are supported.
The current wscons code ignores the unimplemented 38, but then proceeds to
interpret 5 and 100 as further SGR codes.
In many cases, this doesn't much of a problem, because although 5 enables
blink, none of the rasops code supports blink anyway. However, the last value
can potentially set any SGR attribute. So, for example:
CSI 38;5;4m
...will not select colour 4 as the program is expecting, but instead turn on
underlining.
To avoid this, the lastest version of my patch simply discards all values
after a 38 or 48, until the trailing 'm'.
This works to avoid setting unwanted attributes, until such time as 256 colour
support is added, (if this is even desired).
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 08:08:48PM +0100, Paul de Weerd wrote:
> On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
> | On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> | > Hi Crystal,
> | >
> | > I tried your patch on my laptop. With it applied, and my TERM set to
> | > 'xterm', I do get colors in mutt and tmux.
> |
> | Great! Thanks for testing :).
> |
> | > The latter, however, shows
> | > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> | > behavior I don't see with a 'real' xterm.
> |
> | This looks like an off-by-one in the wscons code, (not introduced by me!)
> |
> | Does the following patch, (on top of the last one), fix it?
>
> Fixes only half of it: we're down to one ^@ now (which is not fixed
> with a s/1/2/ in your below diff).
Interestingly, I haven't been able to reproduce this, and when I tested it
originally I was only ever seeing one ^@, which was fixed by the previous
patch.
However, there is another similar off-by-one nearby, which I strongly suspect
is the culprit as fixing it makes the output of 'ESC [ c' more closely match
what a real xterm does.
I'm sending the complete diff again as anybody else testing the version from
this morning will definitely want these two new fixes. So back-out the
previous mini-patch and the main one before applying this.
Hopefully it'll fix the problem.
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select: /* Not defined in xterm
terminfo */
*out = "\033[4~";
return (4);
case KS_Prior:
@@ -174,14 +180,27 @@
case KS_KP_Next:
*out = "\033[6~";
return (4);
+ case KS_Backtab:
+ *out = "\033[Z";
+ return (3);
+ /*
+* Unlike insert, delete, page up, and page down, we purposely don't
+* send the same sequence of \033OE for the non-keypad
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
| On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
| > Hi Crystal,
| >
| > I tried your patch on my laptop. With it applied, and my TERM set to
| > 'xterm', I do get colors in mutt and tmux.
|
| Great! Thanks for testing :).
|
| > The latter, however, shows
| > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
| > behavior I don't see with a 'real' xterm.
|
| This looks like an off-by-one in the wscons code, (not introduced by me!)
|
| Does the following patch, (on top of the last one), fix it?
Fixes only half of it: we're down to one ^@ now (which is not fixed
with a s/1/2/ in your below diff).
Cheers,
Paul
| --- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
| +++ dev/wscons/wsemul_vt100_subr.cWed Jan 4 14:22:05 2023
| @@ -231,7 +231,7 @@
| switch (A3(edp->modif1, edp->modif2, c)) {
| case A3('>', '\0', 'c'): /* DA secondary */
| wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
| - sizeof(WSEMUL_VT_ID2));
| + sizeof(WSEMUL_VT_ID2)-1);
| break;
|
| case A3('\0', '\0', 'J'): /* ED selective erase in display */
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> Hi Crystal,
>
> I tried your patch on my laptop. With it applied, and my TERM set to
> 'xterm', I do get colors in mutt and tmux.
Great! Thanks for testing :).
> The latter, however, shows
> '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> behavior I don't see with a 'real' xterm.
This looks like an off-by-one in the wscons code, (not introduced by me!)
Does the following patch, (on top of the last one), fix it?
--- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
+++ dev/wscons/wsemul_vt100_subr.c Wed Jan 4 14:22:05 2023
@@ -231,7 +231,7 @@
switch (A3(edp->modif1, edp->modif2, c)) {
case A3('>', '\0', 'c'): /* DA secondary */
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
- sizeof(WSEMUL_VT_ID2));
+ sizeof(WSEMUL_VT_ID2)-1);
break;
case A3('\0', '\0', 'J'): /* ED selective erase in display */
Re: Making wscons a bit more like xterm
Hi Crystal,
I tried your patch on my laptop. With it applied, and my TERM set to
'xterm', I do get colors in mutt and tmux. The latter, however, shows
'^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
behavior I don't see with a 'real' xterm.
I like the idea, thanks for your work on this diff.
Paul
On Wed, Jan 04, 2023 at 10:42:56AM -0300, Crystal Kolipe wrote:
| Continuing the move towards xterm becoming the default termtype for the
| console...
|
| This third version of the patchset adds the following features. New features
| since the last version are highlighted first:
|
| NEW - Control sequences for dim text, invisible text, strike through, italic,
| and double underline attributes are now recognised and set flags in
| wscons.
|
| NEW - Rendering of dim, invisible, struck, and double underlined text is now
| supported in rasops32.c, so users of 32bpp displays will see these text
| effects on the console.
|
| NEW - The default number of scrollback screens has been increased from five to
| twenty.
|
| * F1 - F4 now send different sequences.
| * F13 - F24 now send different sequences, but see notes below about F13 - F16.
| * With numlock OFF, keypad 5 is now 'begin' rather than unused.
| * Home, End, keypad home, and keypad end now send different sequences.
| * A new keysym has been added - KS_Backtab.
| * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
| * Shift-F1 - Shift-F12 now send F13 - F24.
| * Five new escape sequences added for cursor movement.
|
| Running with this patch, all of the curses-based programs that I use on a
| regular basis are working and usable with TERM=xterm.
|
| The overall experience is much improved over TERM=vt220, as we get colour.
|
| Even compared to pccon, we gain the ability to use colour together with
| underline, show and hide the cursor, and use backtab. We also gain the
| practicality of relying on a very widely and well supported terminal
| definition, (xterm), which could much more reasonably become the default than
| could pccon.
|
| Additionally, a small side benefit of changing the function key sequences from
| those expected by pccon to those expected by xterm is that any programs or
| scripts which ignore terminfo and are hard coded to work with xterm will now
| work on the console as well.
|
| --- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
| +++ dev/wscons/wsemul_vt100_keys.cMon Jan 2 16:01:42 2023
| @@ -37,11 +37,9 @@
| #include
| #include
|
| +#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
| +
| static const u_char *vt100_fkeys[] = {
| - "\033[11~", /* F1 */
| - "\033[12~",
| - "\033[13~", /* F1-F5 normally don't send codes */
| - "\033[14~",
| "\033[15~", /* F5 */
| "\033[17~", /* F6 */
| "\033[18~",
| @@ -50,18 +48,18 @@
| "\033[21~",
| "\033[23~", /* VT100: ESC */
| "\033[24~", /* VT100: BS */
| - "\033[25~", /* VT100: LF */
| - "\033[26~",
| - "\033[28~", /* help */
| - "\033[29~", /* do */
| - "\033[31~",
| - "\033[32~",
| - "\033[33~",
| - "\033[34~", /* F20 */
| - "\033[35~",
| - "\033[36~",
| - "\033[37~",
| - "\033[38~"
| + "\033[1;2P",/* VT100: LF */
| + "\033[1;2Q",
| + "\033[1;2R",/* help */
| + "\033[1;2S",/* do */
| + "\033[15;2~",
| + "\033[17;2~",
| + "\033[18;2~",
| + "\033[19;2~", /* F20 */
| + "\033[20;2~",
| + "\033[21;2~",
| + "\033[23;2~",
| + "\033[24;2~"
| };
|
| static const u_char *vt100_pfkeys[] = {
| @@ -96,14 +94,22 @@
| edp->translatebuf, edp->flags & VTFL_UTF8));
| }
|
| - if (in >= KS_f1 && in <= KS_f24) {
| - *out = vt100_fkeys[in - KS_f1];
| - return (5);
| + if (in >= KS_f1 && in <= KS_f4) {
| + *out = vt100_pfkeys[in - KS_f1];
| + return (3);
| }
| - if (in >= KS_F1 && in <= KS_F24) {
| - *out = vt100_fkeys[in - KS_F1];
| - return (5);
| + if (in >= KS_F1 && in <= KS_F4) {
| + *out = vt100_pfkeys[in - KS_F1];
| + return (3);
| }
| + if (in >= KS_f5 && in <= KS_f24) {
| + *out = vt100_fkeys[in - KS_f5];
| + return vt100_fkeys_len(in - KS_f5);
| + }
| + if (in >= KS_F5 && in <= KS_F24) {
| + *out = vt100_fkeys[in - KS_F5];
| + return vt100_fkeys_len(in - KS_F5);
| + }
| if (in >= KS_KP_F1 && in <= KS_KP_F4) {
| *out = vt100_pfkeys[in - KS_KP_F1];
| return (3);
| @@ -148,12 +154,12 @@
| }
| switch (in) {
| case KS_Help:
| - *out = vt100_fkeys[15 - 1];
| + *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
| return (5);
| case KS_Execute: /* "Do" */
| - *out =
Re: Making wscons a bit more like xterm
Continuing the move towards xterm becoming the default termtype for the
console...
This third version of the patchset adds the following features. New features
since the last version are highlighted first:
NEW - Control sequences for dim text, invisible text, strike through, italic,
and double underline attributes are now recognised and set flags in
wscons.
NEW - Rendering of dim, invisible, struck, and double underlined text is now
supported in rasops32.c, so users of 32bpp displays will see these text
effects on the console.
NEW - The default number of scrollback screens has been increased from five to
twenty.
* F1 - F4 now send different sequences.
* F13 - F24 now send different sequences, but see notes below about F13 - F16.
* With numlock OFF, keypad 5 is now 'begin' rather than unused.
* Home, End, keypad home, and keypad end now send different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send F13 - F24.
* Five new escape sequences added for cursor movement.
Running with this patch, all of the curses-based programs that I use on a
regular basis are working and usable with TERM=xterm.
The overall experience is much improved over TERM=vt220, as we get colour.
Even compared to pccon, we gain the ability to use colour together with
underline, show and hide the cursor, and use backtab. We also gain the
practicality of relying on a very widely and well supported terminal
definition, (xterm), which could much more reasonably become the default than
could pccon.
Additionally, a small side benefit of changing the function key sequences from
those expected by pccon to those expected by xterm is that any programs or
scripts which ignore terminfo and are hard coded to work with xterm will now
work on the console as well.
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select:
Re: Making wscons a bit more like xterm
Here is an updated version of this patch. Unlike the first version which just added some new control sequences in order to fix the display, this also touches some input code. New in this version: * F1 - F4 now send different sequences. * F13 - F24 now send different sequences, but see notes below about F13 - F16. * With numlock OFF, keypad 5 is now 'begin' rather than unused. * Home, End, keypad home, and keypad end now send different sequences. * A new keysym has been added - KS_Backtab. * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z. * Shift-F1 - Shift-F12 now send F13 - F24. Details: * F1 - F24 now send different sequences F1 - F4 and F17 - F24 now send the sequences expected by the xterm terminfo entry. Those for F1 - F4 are the same as the PF1 - PF4 sequences. The sequences previously used for F1 - F4 did not correspond to a particular hardware terminal. F13 - F16 are interesting. By default, a real xterm running on OpenBSD does not get the sequences it wants for these keys: F13, for example, sends 'ESC O 2 P'. But the terminfo wants 'ESC [ 1 ; 2 P'. The codes that xterm actually sends for these keys by default on OpenBSD are the codes defined in xterm-xf86-v40 and xterm+pcf0, but by using the plain xterm entry, we're expecting the codes for xterm+pcf2. So F13 - F16 have long been broken in xterm, and nobody has complained. F13 and F14 currently work in vt220, but F15 and F16 don't. A real hardware vt220 doesn't have keys marked F15 and F16, instead they are marked help and do. This is reflected in the vt220 terminfo entry. F13 - F16 do currently work in pccon, (without my patch). My patch changes wscons to send the codes that will be recognised by the xterm terminfo entry, making this aspect of TERM=xterm work on the console. So the only users who might be disappointed will be those who currently rely on the buggy behaviour of a real xterm running with the OpenBSD default settings, and who hope or expect to now see this same buggy behaviour on the console. * With numlock OFF, keypad 5 is now 'begin' rather than being unused. Previously, KS_Begin was a NOP. However, the xterm terminfo entry includes a sequence for keypad begin, so I've made wscons send that sequence. This matches the behaviour of a real xterm, so anybody actually using this key in a program should be happy that it now works on the console. * Home, End, keypad home, and keypad end now send different sequences. These codes have been changed to match the xterm terminfo entry. The vt220 terminfo entry does not recognise the old codes for home and end, so only users using pccon or a similar terminal type would have been able to use it in programs that parse terminfo. Now it works fine on the console with TERM=xterm. * A new keysym has been added - KS_Backtab, mapped to Shift-TAB X sees shift-tab as ISO_Left_Tab, and xterm maps this to ESC [ Z, which the terminfo interprets as Backtab. With my patch, a new keysym KS_Backtab is defined, and the console also generates the sequence ESC [ Z. This is then also mapped to Backtab. * Shift-F1 - Shift-F12 now send F13 - F24. This matches what X does, and also makes testing F13 - F24 possible for the majority of users who don't have a keyboard with these physical keys. * Issues remaining * The main area left in which the console does not match a real xterm in terms of keyboard input is in _application mode_. Note to those testing this: when switching between the console and X, the numlock LED on the keyboard may become out of sync with the actual status of numlock on the system. So toggle it before doing further tests. In xterm, with keypad application mode ON, (DECKPAM), and numlock OFF: * The keypad keys work as their cursor movement counterparts on the main keyboard, I.E. they send the sequences for home, end, page up, etc. * The keypad - key sends ESC O m, like a real vt220 * The keypad / * and + keys send ESC O o, ESC O j, and ESC O k, but these do not correspond to a real vt220, because the real vt220 didn't have these keys. In xterm, with keypad application mode ON, (DECKPAM), and numlock ON: * The keypad works the same as in non-application mode, I.E. numbers produce numbers, and / * - and + produce / * - and +. This means that with a real xterm in our current default configuration, you _cannot_ get distinct sequences for the keypad keys. On the console, with keypad application mode ON, (DECKPAM), and numlock OFF: * The keypad keys behave the same as described above for xterm in this situation. On the console, with keypad application mode ON, (DECKPAM), and numlock ON: * The keypad generates sequences consistent with a real vt220 for keys that exist on a real vt220, and ones in a similar vein for those that don't. So on the console, you currently can get distinct sequences. This is a bit awkward, because even though the distinct sequences generated in application mode
Re: Making wscons a bit more like xterm
Hi It is a good idea to make wscons more like xterm, at least so far as setting TERM to xterm will not cause major problems for most programs. Hardly anything uses blinking and the lack of it will bother nobody so TBH I wouldn't worry too much about it. Your diff looks good to me, although it would be nice to label the cases with the escape sequence names like most of the existing ones, eg VPA, HPA, SD, SU, CBT. I am not able to test it however. It looks like SD and SU are VT420 sequences, but we should definitely be careful about ever promising to be VT420 because it has a large variety of weird and wonderful stuff, much of it useless. https://invisible-island.net/xterm/ctlseqs/ctlseqs.html and https://vt100.net/ are useful pages here, although you have probably seen them already. On Sat, 31 Dec 2022, 23:37 Crystal Kolipe, wrote: > The following patch adds five escape sequences to the wscons vt100 > emulation. > > It's one part of a larger set of patches I am working on to make the > console > more like xterm. > >Note: Casual readers of -tech and those not familar with terminfo might >prefer to read my write-up at > https://research.exoticsilicon.com/articles/terminal_emulations > > Why do we want this? > > Currently the console emulates a superset of a subset of vt220 features. > > In other words, it supports most common vt220 sequences and a few > additional > sequences to do things like set colours, (which a real vt220 doesn't > support). > > The problem is that since the terminal emulation has to default to > something > that is universally recognised, it's set by default to vt220, (in > /etc/ttys). > > This means that none of these 'extra' features are available to > curses-based > programs running on the console, unless the user manually fiddles with the > terminal type. > > The terminfo file has long included 'pccon', which claims to support the > OpenBSD console, but this entry has numerous issues such as: > > * Simultaneous use of colour and underline is disabled, even though the > framebuffer console supports it, (presumably because the VGA console does > not). > > * The op entry is hard coded to set black text on a white background > instead > of resetting the terminal to it's default colours. This causes, for > example, > the mutt email client to exit with the terminal inverted, (black text on > a > white background). > > * It doesn't include support for civis or cnorm, (to hide/restore the > cursor), > even though both the framebuffer console and the VGA console support it. > > Even using the vt220 entry as is currently done causes some issues beyond > lack > of colour: > > * F1-F4 are not recognised as they send different sequences to what the > vt220 > entry expects. > > * Also doesn't include civis or cnorm. > > Fixing up the pccon entry is not feasible, as it would take many years for > an > updated version to appear on a sufficient number of systems for it to be > suitable as a default in /etc/ttys. > > The solution: > > If wscons can be made to work adequately with the existing xterm entry in > the > terminfo file, then xterm could eventually become the default terminal > emulation. > > In 2023, the xterm emulation should be almost as universally accepted as > vt220, and allows for many more features such as colour. > > Currently, setting TERM=xterm in the console and starting any curses-based > program will quickly show a lot of breakage. > > Comparing the terminfo entries for vt220 and xterm, the most obvious > functions > that are missing from the vt220 entry and which are not currently > supported by > wscons are: > > Sequence Equivalent to termcap Description > > CSI x T rinscroll back x lines > CSI x S indn scroll forward x lines > CSI x d vpago to line x > CSI x G hpago to column x > CSI Z cbtreverse horizontal tab > > (Note: indices are 1-based and not 0-based.) > > These are the five functions implemented by the attached patch. > > Already, just enabling these functions makes a lot of curses programs run > fine > on the console - in colour - with TERM set to xterm. > > This patch is very unintrusive, and it's hard to see how it could break > anything. It also allows for more widespread testing with TERM=xterm to > find > out what works and what doesn't, and any odd corner cases. > > Beyond this, things become slightly more complicated for several reasons: > > 1. Xterm implements some features such as dim text, strikethrough, double >underline, and italics, which wscons doesn't yet support. I have code > to >implement the first three in rasops32, but didn't make that part of this >diff to keep things simple. > > 2. Xterm implements blinking text, which would require a lot of changes to >implement on the framebuffer console. Should blinking text be > represented >
Making wscons a bit more like xterm
The following patch adds five escape sequences to the wscons vt100 emulation. It's one part of a larger set of patches I am working on to make the console more like xterm. Note: Casual readers of -tech and those not familar with terminfo might prefer to read my write-up at https://research.exoticsilicon.com/articles/terminal_emulations Why do we want this? Currently the console emulates a superset of a subset of vt220 features. In other words, it supports most common vt220 sequences and a few additional sequences to do things like set colours, (which a real vt220 doesn't support). The problem is that since the terminal emulation has to default to something that is universally recognised, it's set by default to vt220, (in /etc/ttys). This means that none of these 'extra' features are available to curses-based programs running on the console, unless the user manually fiddles with the terminal type. The terminfo file has long included 'pccon', which claims to support the OpenBSD console, but this entry has numerous issues such as: * Simultaneous use of colour and underline is disabled, even though the framebuffer console supports it, (presumably because the VGA console does not). * The op entry is hard coded to set black text on a white background instead of resetting the terminal to it's default colours. This causes, for example, the mutt email client to exit with the terminal inverted, (black text on a white background). * It doesn't include support for civis or cnorm, (to hide/restore the cursor), even though both the framebuffer console and the VGA console support it. Even using the vt220 entry as is currently done causes some issues beyond lack of colour: * F1-F4 are not recognised as they send different sequences to what the vt220 entry expects. * Also doesn't include civis or cnorm. Fixing up the pccon entry is not feasible, as it would take many years for an updated version to appear on a sufficient number of systems for it to be suitable as a default in /etc/ttys. The solution: If wscons can be made to work adequately with the existing xterm entry in the terminfo file, then xterm could eventually become the default terminal emulation. In 2023, the xterm emulation should be almost as universally accepted as vt220, and allows for many more features such as colour. Currently, setting TERM=xterm in the console and starting any curses-based program will quickly show a lot of breakage. Comparing the terminfo entries for vt220 and xterm, the most obvious functions that are missing from the vt220 entry and which are not currently supported by wscons are: Sequence Equivalent to termcap Description CSI x T rinscroll back x lines CSI x S indn scroll forward x lines CSI x d vpago to line x CSI x G hpago to column x CSI Z cbtreverse horizontal tab (Note: indices are 1-based and not 0-based.) These are the five functions implemented by the attached patch. Already, just enabling these functions makes a lot of curses programs run fine on the console - in colour - with TERM set to xterm. This patch is very unintrusive, and it's hard to see how it could break anything. It also allows for more widespread testing with TERM=xterm to find out what works and what doesn't, and any odd corner cases. Beyond this, things become slightly more complicated for several reasons: 1. Xterm implements some features such as dim text, strikethrough, double underline, and italics, which wscons doesn't yet support. I have code to implement the first three in rasops32, but didn't make that part of this diff to keep things simple. 2. Xterm implements blinking text, which would require a lot of changes to implement on the framebuffer console. Should blinking text be represented in another way, (boxout? overline? drop shadow?) 3. To make the F1-F4 keys be recognised by the xterm termcap entry requires either changing the sequences they send in wsemul_vt100_keys.c, or changing the various keymaps in wskbdmap_mfii.c to use KS_KP_F1 - KS_KP_F4 instead of KS_f1 - KS_f4. These keys currently do NOT work by default anyway, as the vt220 termcap entry also requires the same change(!), however it would break pccon, which does correctly include the sequences that wscons currently generates. A similar situation exists for F13 - F24, home, and end. The keypad +, -, *, and / keys do currently work with vt220, but break using the xterm entry, (but only for programs that use them via termcap, obviously). Overall, the potential for breakage with this first patch is very small and even with the proposed future changes, should only affect people who are using a non-default configuration, or programs that rely on the terminfo description of the four previously mentioned numeric keypad keys. The potential advantages of
