From 12dd1cd3886b9afc16e9c5ef4957979cfd3a429b Mon Sep 17 00:00:00 2001 From: Bruce Evans Date: Sun, 2 Apr 2017 16:39:39 +0000 Subject: [PATCH] Remove checks that background (bg) colors are not bright and buggy attempts to keep them that way. The bg brightness bit is interpreted as blinking in some modes, but it would barely be useful to disallow setting it when it would give blinking in code which knew when that is. The old code mostly knew this wrong, and added handling errors. It is in fact impossible to know, since future mode switches may change the meaning of the bit many times on the screen and in history. Old versions of vidcontrol disallowed bg color numbers >= 8 in all cases. This is very VGA/syscons-centric. Syscons uses the VGA defaults of blinking fg instead of bright bg in text mode and bright bg in graphics mode. On VGA, this is very easy to toggle at any time, and vt blows away the VGA text mode default at boot time. r146736 changed this to try to allow bg color numbers in graphics mode only. This is even more VGA/syscons-centric, and there are many bugs in this, and many nearby bugs in the parser. These are increased or decreased by differences and bugs in vt and teken. Perhaps the most obvious bug was that almost any vidcontrol command which changes any color or the mode causes an error if the initial fg color is bright. E.g., in syscons text mode, after "vidcontrol lightwhite" to make the fg bright, another "vidcontrol lightwhite" is rejected and buggy fixup code changes the fg to white. This is because the bright fg color creates a bright bg color for the phantom reverse video attribute, so was rejected. (The reverse video attribute is phantom because teken ignores the user's setting of it and simply reverses the fg attributes to create the bg attributes. Sometimes some layer masks off the brightness/blinking bit, but not here.) Perhaps the next most obvious one was that "vidcontrol lightgreen lightblue" was misparsed as 2 settings of the fg instead of 1 setting of the fg and 1 invalid setting of the bg. This is because the parser supports an undocumented syntax with many parsing bugs (an ambiguity gives this one). I recently fix bugs in teken that broke setting of bright fg's and bg's in the normal way. This gave more settings of then, so the old bugs showed up more often. --- usr.sbin/vidcontrol/vidcontrol.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/usr.sbin/vidcontrol/vidcontrol.c b/usr.sbin/vidcontrol/vidcontrol.c index 5c81a855677c..712aeccf0ddf 100644 --- a/usr.sbin/vidcontrol/vidcontrol.c +++ b/usr.sbin/vidcontrol/vidcontrol.c @@ -850,8 +850,7 @@ get_normal_colors(int argc, char **argv, int *_index) normal_fore_color=color; colors_changed = 1; if (*_index < argc - && (color = get_color_number(argv[*_index])) != -1 - && color < 8) { + && (color = get_color_number(argv[*_index])) != -1) { (*_index)++; fprintf(stderr, "\033[=%dG", color); normal_back_color=color; @@ -874,8 +873,7 @@ get_reverse_colors(int argc, char **argv, int *_index) revers_fore_color=color; colors_changed = 1; if (*_index < argc - && (color = get_color_number(argv[*_index])) != -1 - && color < 8) { + && (color = get_color_number(argv[*_index])) != -1) { (*_index)++; fprintf(stderr, "\033[=%dI", color); revers_back_color=color; @@ -1477,18 +1475,8 @@ main(int argc, char **argv) get_normal_colors(argc, argv, &optind); - if (colors_changed || video_mode_changed) { - if (!(new_mode_info.vi_flags & V_INFO_GRAPHICS)) { - if ((normal_back_color < 8) && (revers_back_color < 8)) { - set_colors(); - } else { - revert(); - errx(1, "bg color for text modes must be < 8"); - } - } else { - set_colors(); - } - } + if (colors_changed || video_mode_changed) + set_colors(); if ((optind != argc) || (argc == 1)) usage();