Bug 157017 - vidcontrol(1): "vidcontrol -r" no longer works [regression]
Summary: vidcontrol(1): "vidcontrol -r" no longer works [regression]
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 9.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-13 21:50 UTC by Jens Schweikhardt
Modified: 2018-05-20 23:52 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Schweikhardt 2011-05-13 21:50:06 UTC
Apparently, "vidcontrol -r foreground background" no longer works. I
don't know when exactly it stopped.

I use it via /etc/rc.conf with

allscreens_flags="-r cyan blue"

The symptom is that running "man man" still uses black on white for reverse
video instead of cyan and blue. My TERM is cons31l.

How-To-Repeat: To reproduce:

$ vidcontrol -r cyan blue
$ man man
Comment 1 Bruce Evans freebsd_committer freebsd_triage 2011-05-14 12:04:48 UTC
On Fri, 13 May 2011, Jens Schweikhardt wrote:

>> Description:
> Apparently, "vidcontrol -r foreground background" no longer works. I don't know when exactly it stopped.
>
> I use it via /etc/rc.conf with
>
> allscreens_flags="-r cyan blue"
>
> The symptom is that running "man man" still uses black on white for reverse video instead of cyan and blue. My TERM is cons31l.

syscons used to have independently programmable reverse video colors
(tcp->rev_color for these and tcp->std_color for normal colors).
This functionality has been lost, so all the escape sequences that
depend on it are broken.  Two of the broken escape sequences are
"ESC [ = <color> H" and "ESC [ = <color> I", which are still used by
vidcontrol -r.  The main other ones are "ESC [ <selector> ; <color> x",
where <selector> is "5", "6" or "7".

syscons should have had independendly programmable colors for all
(non-color) "ANSI" attributes (i.e., for all of normal video, reverse
video, blink and underline, not just for normal and reverse video).
For consoles that don't support blink or underline, it fakes these
attributes using colors (if these are available).  Often it makes very
poor choices for these colors and you can do better by choosing the
colors yourself.  This works best if the colors are never changed as
pure colors.

The "ESC [ ... x" sequences are old pc3 ones which were always supported
by syscons until the breakage.  In /etc/termcap, they seem to only be
used for 'op' for pc3, and there only as "ESC [ x" which is short for
"ESC [ 0 x" which means "reset colors to defaults".  The independently
programmable colors are not really used by this -- the independent
programming is just undone.  The one with "5" selector is equivalent to
"ESC [ <color> I" and the one with the "6" selector is equivalent to
"ESC [ <color> H".  The only differences are that the "x" sequences are
less verbose and use the "IBM PC" color mapping, while the "H/I" sequences
use the "ANSI" color mapping.  Other "x" selectors provided functionality
that is either not available or more verbosely available near the "H/I"
sequences.  It is a feature that there is no "ANSI" sequence equivalent
to "ESC [ 0 x".  This makes settings of the reverse colors fairly sticky,
so that they are not clobbered by other "ANSI" color sequences.  Apart
"ESC [ 0 x", only a terminal reset ("ESC c") clobbers the reverse color
settings.

I don't use vidcontrol -r, but have used the "x" escape sequences to
set sticky reverse colors in syscons for almost 20 years, and similar
sequences, some written by me, in other drivers/OS's for another 5
years.  Now I use the following in ~/.profile.  It partially works
around the broken "x" sequences by using "ANSI" colors more.

% case $TERM in
% cons25)
% 	printf '\033[x\033[2;6x\033[1;0x\033[6;7x\033[5;4x'

The old version just uses this "x" sequence.  It does:
0) reset normal and reverse colors to defaults
2) set normal foreground color
1) set normal background color
6) set reverse foreground color
5) set reverse background color
This still works with old kernels.  IIRC, the "x" sequences are silentl
yignored by now kernels for all selectors, although the functionality
for implementing them has only been lost for the reverse color selectors.

% 	printf '\033[=3F\033[=0G'

These "F" and "G" sequences do as much as possible with the unbroken
sequences near the "H" and "I" ones -- just set the normal foreground
and background colors.  This just repeats the settings made by "2x"
and "1x" on old kernels.  Don't bother trying to use the "H" and "I"
sequences corresponding to "6x" and "5x", since at best they are
silently ignored on new kernels.

% 	;;
% linux)
% 	printf '\033[36;40m\033[1;4]\033[8]'

Start by setting some "ANSI" colors.  I forget what the "]" sequence does.
It may even work.

% 	;;
% esac
% case $TERM in
% cons25)
% 	TERMCAP="$TERM:md=\E[1;37m:so=\E[37;44m:se=\E[39;49m:us=\E[1;33;44m:ue=\E[22;39;49m:tc=$TERM:"
% 	;;
% esac

Hack on termcap to set and restore "ANSI" colors the same as the "x" sequence
would do if it weren't broken, plus handle underline like the "x" sequence
should be able to do.  Blink doesn't seem to be mappable to termcap, so don't
do anything for it.

Fixing this, and using termcap, actually improved the rendition of man
pages, but it loses the stickiness feature.  I had to be more careful
with the color choices for normal and reverse, and used the same method
to improve underline.  Unlike unbroken "x" sequences, this only works
if termcap is used.  Then it works fairly well -- the attribute "end"
sequences just need to reset to whatever the "x" sequences would give.
The main problem with this is that the system termcap can't hard-code
individual users' color choices like this.

Bruce
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:52:05 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"