Project

General

Profile

Bug #10360

terminfo: sun-color has 256 colors

Added by Toomas Soome 5 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
system data
Start date:
2019-02-08
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

Update terminfo to announce number of colors.


Files

wscons256.png (65.6 KB) wscons256.png Joshua M. Clulow, 2019-02-09 07:45 PM
Screenshot 2019-02-10 at 14.20.48.png (368 KB) Screenshot 2019-02-10 at 14.20.48.png Toomas Soome, 2019-02-10 12:24 PM

History

#1

Updated by Joshua M. Clulow 5 months ago

I did some testing of the xterm 256 colour sequences on an OpenIndiana machine which does not have support for the sequences, to see what will happen if you use an old console to SSH to a machine with updated terminfo definitions.

At the bottom of the screenshot is an actual xterm as a baseline of what's supposed to happen. At the top is wscons in the OI guest, showing the wrong colours but nothing otherwise out of place, etc.

To explain exactly what's happening in wscons, note that the escape sequence here is CSI 38 ; 5 ; X m where X is the colour number (printed on screen here as 000, 001, etc). TEM presently ignores parameter 38, then interprets 5 as "blink" which also appears to do nothing; it then misinterprets the last parameter (X) as a regular SGR parameter. Thus, 001 is in bold, 007 is in reverse video, 30-47 are (incorrect) foreground colours, etc.

When updating the terminfo definition, there are two cases of mismatch we should consider:

  1. User of framebuffer console has an up-to-date illumos which supports 256 colours, and they SSH to a remote system with an out-of-date sun-color terminfo definition; this user will not see 256 colours from the remote host, but nothing bad will happen
  2. User of framebuffer console has an old illumos, or even Solaris, system which does not support 256 colours; they SSH to a remote system with an updated sun-color terminfo definition which suggests their terminal does have 256 colour support; they will see the incorrect colours as per the screenshot if they have software using 256 colour sequences

It seems much more likely that a serious user of the framebuffer console will hit case 1, and that almost nobody ends up in case 2 -- at least not often or for very long.

It will take years for systems running other operating systems (Linux, BSD, Mac OS, etc) to get an updated terminfo definition that includes our new definitions. If we were to require a new terminfo definition (e.g., sun-256color) then we're instead requiring the common case (case 1) users to set TERM=sun-color any time they connect to a remote host, which seems like a much bigger inconvenience.

I think this means it's reasonable that we amend our sun-color definition rather than create a new definition.

#2

Updated by Toomas Soome 5 months ago

Joshua Clulow wrote:

I did some testing of the xterm 256 colour sequences on an OpenIndiana machine which does not have support for the sequences, to see what will happen if you use an old console to SSH to a machine with updated terminfo definitions.

At the bottom of the screenshot is an actual xterm as a baseline of what's supposed to happen. At the top is wscons in the OI guest, showing the wrong colours but nothing otherwise out of place, etc.

To explain exactly what's happening in wscons, note that the escape sequence here is CSI 38 ; 5 ; X m where X is the colour number (printed on screen here as 000, 001, etc). TEM presently ignores parameter 38, then interprets 5 as "blink" which also appears to do nothing; it then misinterprets the last parameter (X) as a regular SGR parameter. Thus, 001 is in bold, 007 is in reverse video, 30-47 are (incorrect) foreground colours, etc.

When updating the terminfo definition, there are two cases of mismatch we should consider:

  1. User of framebuffer console has an up-to-date illumos which supports 256 colours, and they SSH to a remote system with an out-of-date sun-color terminfo definition; this user will not see 256 colours from the remote host, but nothing bad will happen
  2. User of framebuffer console has an old illumos, or even Solaris, system which does not support 256 colours; they SSH to a remote system with an updated sun-color terminfo definition which suggests their terminal does have 256 colour support; they will see the incorrect colours as per the screenshot if they have software using 256 colour sequences

It seems much more likely that a serious user of the framebuffer console will hit case 1, and that almost nobody ends up in case 2 -- at least not often or for very long.

It will take years for systems running other operating systems (Linux, BSD, Mac OS, etc) to get an updated terminfo definition that includes our new definitions. If we were to require a new terminfo definition (e.g., sun-256color) then we're instead requiring the common case (case 1) users to set TERM=sun-color any time they connect to a remote host, which seems like a much bigger inconvenience.

I think this means it's reasonable that we amend our sun-color definition rather than create a new definition.

And here is the 256-color console:

#3

Updated by Joshua M. Clulow 5 months ago

Additional Testing Notes

Toomas said in mail:

For testing I did use vim on console with syntax on. Not too much, but it surely was colored with different files.

#4

Updated by Electric Monk 5 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

git commit 5252287263bfeeffa673dbbb900fdb6ff67d3a0d

commit  5252287263bfeeffa673dbbb900fdb6ff67d3a0d
Author: Toomas Soome <tsoome@me.com>
Date:   2019-02-16T06:44:06.000Z

    10360 terminfo: sun-color has 256 colors
    Reviewed by: Andy Stormont <astormont@racktopsystems.com>
    Approved by: Joshua M. Clulow <josh@sysmgr.org>

Also available in: Atom PDF