Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 15, 2020 at 10:26:12AM -0600, Theo de Raadt wrote:
> > So here is a new iteration taking feedback into account, using the
> > #if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching
> > the foreground color of printed kernel messages to light cyan to improve
> > contrast and readability.
>
> I really dislike how two issues are being mixed into one diff.
Right. This was to allow easier testing by having only one diff to
apply, and that's why I wasn't explicitely asking for OKs.
So let's move forward with this, here is a diff addressing only the
color palette changes.
OK?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.63
diff -u -p -r1.63 rasops.c
--- sys/dev/rasops/rasops.c 11 Jul 2020 15:02:52 - 1.63
+++ sys/dev/rasops/rasops.c 15 Jul 2020 14:55:45 -
@@ -47,7 +47,8 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#if WS_DEFAULT_BG == WSCOL_WHITE
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +65,25 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
Re: Use VGA text mode palette RGB values in rasops(9)
> So here is a new iteration taking feedback into account, using the > #if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching > the foreground color of printed kernel messages to light cyan to improve > contrast and readability. I really dislike how two issues are being mixed into one diff.
Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 08, 2020 at 12:37:11PM +1000, Jonathan Gray wrote:
> Thanks for the explanation. The proposal makes more sense from the
> point of view of the existing colours being darker for openboot black
> on white.
>
> #if WS_DEFAULT_BG == WSCOL_WHITE
>
> old
>
> #else
>
> new
>
> #endif
>
> would have made that a bit more readable.
Yes, this is indeed better, thanks for the suggestion.
> It is interesting that the choice of blue comes up as being problematic
> in xterm as well when reading XTerm-col.ad
>
> For us though it really comes down to white on black (!sparc64), black
> on white (sparc64) and white on blue for the kernel.
I understand the concern is about the contrast for printed kernel
messages.
Currently, output originating from the kernel is displayed using
WSCOL_WHITE on WSCOL_BLUE, which translates to NORMAL_WHITE on
NORMAL_BLUE, and I agree that 0xaa as foreground on a blue
background is not optimal, I think I raised the issue a few years
ago as it's what we currently get when booting in BIOS mode. But
it doesn't have to be this way, it could be changed.
> I agree with the sentiment that people should be using X and leave
> rasops/wscons as simple as possible.
I understand some developers share this position, however we do have
supported platforms (loongson being one, for example), on which X is
not realistically usable.
So here is a new iteration taking feedback into account, using the
#if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching
the foreground color of printed kernel messages to light cyan to improve
contrast and readability.
Does this proposal look reasonable?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.63
diff -u -p -r1.63 rasops.c
--- sys/dev/rasops/rasops.c 11 Jul 2020 15:02:52 - 1.63
+++ sys/dev/rasops/rasops.c 15 Jul 2020 14:55:45 -
@@ -47,7 +47,8 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#if WS_DEFAULT_BG == WSCOL_WHITE
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +65,25 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
Index: sys/dev/wscons/wsemul_vt100.c
===
RCS file: /cvs/src/sys/dev/wscons/wsemul_vt100.c,v
retrieving revision 1.39
diff -u -p -r1.39 wsemul_vt100.c
--- sys/dev/wscons/wsemul_vt100.c 25 May 2020 09:55:49 - 1.39
+++ sys/dev/wscons/wsemul_vt100.c 15 Jul 2020 14:55:45 -
@@ -165,13 +165,13 @@ wsemul_vt100_cnattach(const struct wsscr
edp->cbcookie = NULL;
#ifndef WS_KERNEL_FG
-#define WS_KERNEL_FG WSCOL_WHITE
+#define WS_KERNEL_FG WSCOL_CYAN
#endif
#ifndef WS_KERNEL_BG
#define WS_KERNEL_BG WSCOL_BLUE
#endif
#ifndef WS_KERNEL_COLATTR
-#define WS_KERNEL_COLATTR 0
+#define WS_KERNEL_COLATTR WSATTR_HILIT
#endif
#ifndef WS_KERNEL_MONOATTR
#define WS_KERNEL_MONOATTR 0
Re: Use VGA text mode palette RGB values in rasops(9)
On Tue, Jul 07, 2020 at 05:55:32PM +0200, Frederic Cambus wrote: > On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote: > > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > > Hi tech@, > > > > > > The recent spike of interest around framebuffer consoles has prompted > > > me to revisit a proposal I sent back in early 2017 [1]. > > > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > > from the original rasops palette carefully matched what OpenFirmware > > > uses for the console on sparc64. > > > > > > Therefore, I propose to default on using the proper VGA text mode palette > > > RGB values, and to keep the original rasops color palette on sparc64. > > > > > > The differences between the two palettes can be seen here [2]. > > > > > > Comments? OK? > > > > Why is it important to match VGA colours? > > We don't try to match video modes or fonts. > > In case it wasn't obvious by comparing the two palettes, the main problem > with the rasops palette it that the NORMAL_RED, NORMAL_GREEN, NORMAL_BLUE, > NORMAL_MAGENTA and NORMAL_CYAN colors are too dark. > > NORMAL_BLUE is especially problematic as it's very difficult to read on > a black background. > > It is used as the default color for comments in vim. It's also (I know I'm > not going to make any friends here) the color used to "highlight" (ahem) > directories in colorls. > > One can test in frame buffer consoles by doing: > > export TERM=wsvt25 > > And run either vim or colorls -G. Thanks for the explanation. The proposal makes more sense from the point of view of the existing colours being darker for openboot black on white. #if WS_DEFAULT_BG == WSCOL_WHITE old #else new #endif would have made that a bit more readable. It is interesting that the choice of blue comes up as being problematic in xterm as well when reading XTerm-col.ad For us though it really comes down to white on black (!sparc64), black on white (sparc64) and white on blue for the kernel. I agree with the sentiment that people should be using X and leave rasops/wscons as simple as possible.
Re: Use VGA text mode palette RGB values in rasops(9)
As you get older, you gradually get cataracts -which makes your lenses go yellow. This has the effect of reducing the contrast you experience with blue. Blue against back is very problematic, while blue is generally not great anyway. Eventually, you need an operation to replace your lenses replaced with plastic ones, after which you can see ultraviolet. I am at the stage where dark blue on black is nearly invisible. Probably most males over 60 will experience this unless already colourblind. If you are designing UIs you need to know this. And at least some of us have been Unix users since the 1970's when X did not exist, and are likely to use text mode a lot. On Tue, 7 Jul 2020 at 18:37, Stuart Henderson wrote: > On 2020/07/07 15:16, Frederic Cambus wrote: > > Hi tech@, > > > > The recent spike of interest around framebuffer consoles has prompted > > me to revisit a proposal I sent back in early 2017 [1]. > > > > Aesthetics considerations aside, kettenis@ raised the concern that > colors > > from the original rasops palette carefully matched what OpenFirmware > > uses for the console on sparc64. > > ..and they're a good choice on sparc64 console with the pale background > that the palette is normally used with. > > I agree that the blue we have now is a bit too dark against a black > background. > >
Re: Use VGA text mode palette RGB values in rasops(9)
Mark Kettenis wrote: > Unless there is an overwhelming majority of users/developers who thing > the colors should indeed be changed. If there is a significant > minority that thinks the current colormap severely impacts the > usability of the framebuffer console, then maybe an interface to > change the colormap from userland is needed. Such an interface already exists, it is known as X. I'm not being ironic. The console code is sufficient for minor use, or controlled environment use, and after that X has the fancy features rather than replicating additional support code in the kernel. It satisfies needs, not fan clubs.
Re: Use VGA text mode palette RGB values in rasops(9)
> Date: Tue, 7 Jul 2020 17:55:32 +0200 > From: Frederic Cambus > > On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote: > > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > > Hi tech@, > > > > > > The recent spike of interest around framebuffer consoles has prompted > > > me to revisit a proposal I sent back in early 2017 [1]. > > > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > > from the original rasops palette carefully matched what OpenFirmware > > > uses for the console on sparc64. > > > > > > Therefore, I propose to default on using the proper VGA text mode palette > > > RGB values, and to keep the original rasops color palette on sparc64. > > > > > > The differences between the two palettes can be seen here [2]. > > > > > > Comments? OK? > > > > Why is it important to match VGA colours? > > We don't try to match video modes or fonts. > > In case it wasn't obvious by comparing the two palettes, the main problem > with the rasops palette it that the NORMAL_RED, NORMAL_GREEN, NORMAL_BLUE, > NORMAL_MAGENTA and NORMAL_CYAN colors are too dark. > > NORMAL_BLUE is especially problematic as it's very difficult to read on > a black background. But NORMAL_BLUE is used as the background color for kernel messages. So making it brighter reduces contrast there. Unless there is an overwhelming majority of users/developers who thing the colors should indeed be changed. If there is a significant minority that thinks the current colormap severely impacts the usability of the framebuffer console, then maybe an interface to change the colormap from userland is needed. Cheers, Mark
Re: Use VGA text mode palette RGB values in rasops(9)
On 2020/07/07 15:16, Frederic Cambus wrote: > Hi tech@, > > The recent spike of interest around framebuffer consoles has prompted > me to revisit a proposal I sent back in early 2017 [1]. > > Aesthetics considerations aside, kettenis@ raised the concern that colors > from the original rasops palette carefully matched what OpenFirmware > uses for the console on sparc64. ..and they're a good choice on sparc64 console with the pale background that the palette is normally used with. I agree that the blue we have now is a bit too dark against a black background.
Re: Use VGA text mode palette RGB values in rasops(9)
wrote: > Related, I looked through the xterm code to see how hard it would > be to use some of it directly in the wscons system for accurate > emulation, and it looked pretty challenging to me. Fixing problems > piecemeal is probably easier than trying to reuse code. It was obvious 25-30 years ago to choose vt220 as the what-to-emulate. In those days, there were still a lot of proprietary unix systems, and their termcaps were not being updated, so the "pccons" hackjob was highly inconvient when ssh'ing between machines. So vt220 was an easier choice. Highly compatible with the various termcap generations on those proprietary operating systems; most of their termcaps were quite restricted in what they said a vt220 was, so it worked well. Most of the architectures therefore got vt220 emulation, but since Torek's sparc code had early "sun" terminal emulation, the code also grew the option of servicing that emulation instead. It was convenient. Likewise, the "sun" termcap entry was high-quality on proprietary operating systems. Nowadays, if xterm emulation was the target (instead), it would be more suitable than either choice. Highly desireable in my mind. Imagine if /etc/ttys was "xterm" on all systems. I believe it only needs to be a fairly minimal emulation, with tty size issues are handled TIOCGWINSZ. After all, the vt220 emulation we have is already a hackjob. It has misbehaving features, the 24 vs 25 line issue, enhancements which are incompatible with a real vt220, gaps in emulating obscure features noone wants, and colour support which isn't really standard. >From a risk perspective, unless something is 100% compatible, and accepts nothing else as input, it isn't compatible and there are risks introduced because it behaves different from the real thing. We never seem to get close to perfect emulation. Just perfect enough to match termcap...
Re: Use VGA text mode palette RGB values in rasops(9)
I have also noticed that comments are hard to read in color-vim because of the dark blue on black; increasing the intensity would be a trivial improvement. I have thought about testing a bold attribute implementation by way of shift-and-overlay of the font bitmap so all the colors could be full intensity. The effect would be resolution dependent, but probably superior for at least the 12x24 and 16x32 fonts. 32x64 might need triple striking. An actual bold font for each size would be superior quality and speed at a space cost, of course. Related, I looked through the xterm code to see how hard it would be to use some of it directly in the wscons system for accurate emulation, and it looked pretty challenging to me. Fixing problems piecemeal is probably easier than trying to reuse code. Original Message Subject: Re: Use VGA text mode palette RGB values in rasops(9) From: "Theo de Raadt" Date: Tue, July 07, 2020 9:07 am To: Frederic Cambus Cc: tech@openbsd.org, Jonathan Gray Frederic Cambus wrote: > One can test in frame buffer consoles by doing: > > export TERM=wsvt25 > > And run either vim or colorls -G. > Furthermore the situation is just beyond ridiculous. On the one hand your diff is talking about minimizing the differences between terminals, but your example immediately heads in the opposite direction by SELECTING for divergent configuration -- which I suspect noone except you uses. This termcap mess should never have happened. Up until about 10 years ago, pointless and accidental divergence in console emulators ended up being reflected in termcap entries *which to a large degree noone used, except for the people making the termcap entries*, and the situation is so retarded, because is ENTRENCHES differences rather than recognizing the differences shouldn't have existed. The console emulators SHOULD HAVE become more mundane and less featureful, they should have become closer to a clean blend of vt220 + xterm. But no! People focused on extremely narrow details and hid them behind TERM feature flags, and avoided focusing on the big picture of improving ease of utilization and compatibility. It is very sad.
Re: Use VGA text mode palette RGB values in rasops(9)
Frederic Cambus wrote: > One can test in frame buffer consoles by doing: > > export TERM=wsvt25 > > And run either vim or colorls -G. > Furthermore the situation is just beyond ridiculous. On the one hand your diff is talking about minimizing the differences between terminals, but your example immediately heads in the opposite direction by SELECTING for divergent configuration -- which I suspect noone except you uses. This termcap mess should never have happened. Up until about 10 years ago, pointless and accidental divergence in console emulators ended up being reflected in termcap entries *which to a large degree noone used, except for the people making the termcap entries*, and the situation is so retarded, because is ENTRENCHES differences rather than recognizing the differences shouldn't have existed. The console emulators SHOULD HAVE become more mundane and less featureful, they should have become closer to a clean blend of vt220 + xterm. But no! People focused on extremely narrow details and hid them behind TERM feature flags, and avoided focusing on the big picture of improving ease of utilization and compatibility. It is very sad.
Re: Use VGA text mode palette RGB values in rasops(9)
> One can test in frame buffer consoles by doing: > > export TERM=wsvt25 > > And run either vim or colorls -G. Why not set it to wyse30? Come on. We chose a default. If you change it to some arbitrary value, then you get to reap the upsides and downsides. Our emulation is *NOT* 'NetBSD "wscons" emulator in vt220 mode.'.
Re: Use VGA text mode palette RGB values in rasops(9)
On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote: > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > The recent spike of interest around framebuffer consoles has prompted > > me to revisit a proposal I sent back in early 2017 [1]. > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > from the original rasops palette carefully matched what OpenFirmware > > uses for the console on sparc64. > > > > Therefore, I propose to default on using the proper VGA text mode palette > > RGB values, and to keep the original rasops color palette on sparc64. > > > > The differences between the two palettes can be seen here [2]. > > > > Comments? OK? > > Why is it important to match VGA colours? > We don't try to match video modes or fonts. In case it wasn't obvious by comparing the two palettes, the main problem with the rasops palette it that the NORMAL_RED, NORMAL_GREEN, NORMAL_BLUE, NORMAL_MAGENTA and NORMAL_CYAN colors are too dark. NORMAL_BLUE is especially problematic as it's very difficult to read on a black background. It is used as the default color for comments in vim. It's also (I know I'm not going to make any friends here) the color used to "highlight" (ahem) directories in colorls. One can test in frame buffer consoles by doing: export TERM=wsvt25 And run either vim or colorls -G.
Re: Use VGA text mode palette RGB values in rasops(9)
> From: "Theo de Raadt" > Date: Tue, 07 Jul 2020 08:49:41 -0600 > > Jonathan Gray wrote: > > > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > > Hi tech@, > > > > > > The recent spike of interest around framebuffer consoles has prompted > > > me to revisit a proposal I sent back in early 2017 [1]. > > > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > > from the original rasops palette carefully matched what OpenFirmware > > > uses for the console on sparc64. > > > > > > Therefore, I propose to default on using the proper VGA text mode palette > > > RGB values, and to keep the original rasops color palette on sparc64. > > > > > > The differences between the two palettes can be seen here [2]. > > > > > > Comments? OK? > > > > Why is it important to match VGA colours? > > We don't try to match video modes or fonts. > > I also don't understand the fuss, because during bootup we are effectively > flipping between a series of views (without retaining pre-existing text, > just simply clearing the screen and starting all over again). Since that > is the situation, why does any of the look matter, as long as each new load > is similar (or better), isn't that good enough? I think this might matter > if the pre-existing text was *retained*, rather than cleared away.. Which happens on most sparc64 framebuffer consoles.
Re: Use VGA text mode palette RGB values in rasops(9)
Jonathan Gray wrote: > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > The recent spike of interest around framebuffer consoles has prompted > > me to revisit a proposal I sent back in early 2017 [1]. > > > > Aesthetics considerations aside, kettenis@ raised the concern that colors > > from the original rasops palette carefully matched what OpenFirmware > > uses for the console on sparc64. > > > > Therefore, I propose to default on using the proper VGA text mode palette > > RGB values, and to keep the original rasops color palette on sparc64. > > > > The differences between the two palettes can be seen here [2]. > > > > Comments? OK? > > Why is it important to match VGA colours? > We don't try to match video modes or fonts. I also don't understand the fuss, because during bootup we are effectively flipping between a series of views (without retaining pre-existing text, just simply clearing the screen and starting all over again). Since that is the situation, why does any of the look matter, as long as each new load is similar (or better), isn't that good enough? I think this might matter if the pre-existing text was *retained*, rather than cleared away..
Re: Use VGA text mode palette RGB values in rasops(9)
> Date: Tue, 7 Jul 2020 15:16:33 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from the original rasops palette carefully matched what OpenFirmware
> uses for the console on sparc64.
>
> Therefore, I propose to default on using the proper VGA text mode palette
> RGB values, and to keep the original rasops color palette on sparc64.
>
> The differences between the two palettes can be seen here [2].
>
> Comments? OK?
If there ever was a true bikeshed...
I must say I like the current rasops colors better, so my vote would
be to keep things as they are and avoid extra #ifdefs in the code.
> [1] https://marc.info/?l=openbsd-tech&m=148374502927423&w=2
> [2]
> https://www.cambus.net/openbsd-framebuffer-console-and-custom-color-palettes/
>
> Index: sys/dev/rasops/rasops.c
> ===
> RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 rasops.c
> --- sys/dev/rasops/rasops.c 16 Jun 2020 21:49:30 - 1.62
> +++ sys/dev/rasops/rasops.c 7 Jul 2020 09:10:08 -
> @@ -47,7 +47,26 @@
>
> /* ANSI colormap (R,G,B) */
>
> -#define NORMAL_BLACK0x00
> +#ifndef __sparc64__
> +#define NORMAL_BLACK0x00/* VGA text mode palette */
> +#define NORMAL_RED 0xaa
> +#define NORMAL_GREEN0x00aa00
> +#define NORMAL_BROWN0xaa5500
> +#define NORMAL_BLUE 0xaa
> +#define NORMAL_MAGENTA 0xaa00aa
> +#define NORMAL_CYAN 0x00
> +#define NORMAL_WHITE0xaa
> +
> +#define HILITE_BLACK0x55
> +#define HILITE_RED 0xff
> +#define HILITE_GREEN0x55ff55
> +#define HILITE_BROWN0x55
> +#define HILITE_BLUE 0xff
> +#define HILITE_MAGENTA 0xff55ff
> +#define HILITE_CYAN 0x55
> +#define HILITE_WHITE0xff
> +#else
> +#define NORMAL_BLACK0x00/* Rasops palette */
> #define NORMAL_RED 0x7f
> #define NORMAL_GREEN0x007f00
> #define NORMAL_BROWN0x7f7f00
> @@ -64,6 +83,7 @@
> #define HILITE_MAGENTA 0xff00ff
> #define HILITE_CYAN 0x00
> #define HILITE_WHITE0xff
> +#endif
>
> const u_char rasops_cmap[256 * 3] = {
> #define _C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
> 0xff)
>
>
Re: Use VGA text mode palette RGB values in rasops(9)
On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from the original rasops palette carefully matched what OpenFirmware
> uses for the console on sparc64.
>
> Therefore, I propose to default on using the proper VGA text mode palette
> RGB values, and to keep the original rasops color palette on sparc64.
>
> The differences between the two palettes can be seen here [2].
>
> Comments? OK?
Why is it important to match VGA colours?
We don't try to match video modes or fonts.
>
> [1] https://marc.info/?l=openbsd-tech&m=148374502927423&w=2
> [2]
> https://www.cambus.net/openbsd-framebuffer-console-and-custom-color-palettes/
>
> Index: sys/dev/rasops/rasops.c
> ===
> RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 rasops.c
> --- sys/dev/rasops/rasops.c 16 Jun 2020 21:49:30 - 1.62
> +++ sys/dev/rasops/rasops.c 7 Jul 2020 09:10:08 -
> @@ -47,7 +47,26 @@
>
> /* ANSI colormap (R,G,B) */
>
> -#define NORMAL_BLACK0x00
> +#ifndef __sparc64__
> +#define NORMAL_BLACK0x00/* VGA text mode palette */
> +#define NORMAL_RED 0xaa
> +#define NORMAL_GREEN0x00aa00
> +#define NORMAL_BROWN0xaa5500
> +#define NORMAL_BLUE 0xaa
> +#define NORMAL_MAGENTA 0xaa00aa
> +#define NORMAL_CYAN 0x00
> +#define NORMAL_WHITE0xaa
> +
> +#define HILITE_BLACK0x55
> +#define HILITE_RED 0xff
> +#define HILITE_GREEN0x55ff55
> +#define HILITE_BROWN0x55
> +#define HILITE_BLUE 0xff
> +#define HILITE_MAGENTA 0xff55ff
> +#define HILITE_CYAN 0x55
> +#define HILITE_WHITE0xff
> +#else
> +#define NORMAL_BLACK0x00/* Rasops palette */
> #define NORMAL_RED 0x7f
> #define NORMAL_GREEN0x007f00
> #define NORMAL_BROWN0x7f7f00
> @@ -64,6 +83,7 @@
> #define HILITE_MAGENTA 0xff00ff
> #define HILITE_CYAN 0x00
> #define HILITE_WHITE0xff
> +#endif
>
> const u_char rasops_cmap[256 * 3] = {
> #define _C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
> 0xff)
>
>
Use VGA text mode palette RGB values in rasops(9)
Hi tech@,
The recent spike of interest around framebuffer consoles has prompted
me to revisit a proposal I sent back in early 2017 [1].
Aesthetics considerations aside, kettenis@ raised the concern that colors
from the original rasops palette carefully matched what OpenFirmware
uses for the console on sparc64.
Therefore, I propose to default on using the proper VGA text mode palette
RGB values, and to keep the original rasops color palette on sparc64.
The differences between the two palettes can be seen here [2].
Comments? OK?
[1] https://marc.info/?l=openbsd-tech&m=148374502927423&w=2
[2]
https://www.cambus.net/openbsd-framebuffer-console-and-custom-color-palettes/
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.62
diff -u -p -r1.62 rasops.c
--- sys/dev/rasops/rasops.c 16 Jun 2020 21:49:30 - 1.62
+++ sys/dev/rasops/rasops.c 7 Jul 2020 09:10:08 -
@@ -47,7 +47,26 @@
/* ANSI colormap (R,G,B) */
-#defineNORMAL_BLACK0x00
+#ifndef __sparc64__
+#defineNORMAL_BLACK0x00/* VGA text mode palette */
+#defineNORMAL_RED 0xaa
+#defineNORMAL_GREEN0x00aa00
+#defineNORMAL_BROWN0xaa5500
+#defineNORMAL_BLUE 0xaa
+#defineNORMAL_MAGENTA 0xaa00aa
+#defineNORMAL_CYAN 0x00
+#defineNORMAL_WHITE0xaa
+
+#defineHILITE_BLACK0x55
+#defineHILITE_RED 0xff
+#defineHILITE_GREEN0x55ff55
+#defineHILITE_BROWN0x55
+#defineHILITE_BLUE 0xff
+#defineHILITE_MAGENTA 0xff55ff
+#defineHILITE_CYAN 0x55
+#defineHILITE_WHITE0xff
+#else
+#defineNORMAL_BLACK0x00/* Rasops palette */
#defineNORMAL_RED 0x7f
#defineNORMAL_GREEN0x007f00
#defineNORMAL_BROWN0x7f7f00
@@ -64,6 +83,7 @@
#defineHILITE_MAGENTA 0xff00ff
#defineHILITE_CYAN 0x00
#defineHILITE_WHITE0xff
+#endif
const u_char rasops_cmap[256 * 3] = {
#define_C(x) ((x) & 0xff) >> 16, ((x) & 0x00ff00) >> 8, ((x) &
0xff)
