Re: Support 256 colours on wscons

[Crystal Kolipe <kolipe.c%exoticsilicon.com@localhost>]

Hi,

On Tue, Oct 28, 2025 at 12:41:51PM +0000, nia wrote:
> Hi! Thanks for working on this.
> 
> While testing this patch (with a little script that outputs all the
> xterm 256 color escapes), I noticed that it only works for 32-bit
> wsdisplays.
> 
> You can try out a range of colour depths using the "vesa" option
> in the bios bootloader, for example, in qemu-system-i386.
> 
> I've made a few adjustments to dev/rasops so that 8/16/24-bit
> wsdisplays can also use the 256-color extensions. It seems to work.

16-bit and 24-bit should work OK, but 8-bit will likely cause some problems:

> I'm not sure the reproduction on 8-bit displays is 100% perfect
> (certainly the antialiasing could be prettier when using an
> antialiased font), but it's definitely usable.

There are at least three issues with supporting 8-bit displays:

First, some of the palette colours will be mapped to the same RGB values, this
is probably easiest to see on the greyscale ramp 232-255.  So a program using
the 256 colour support might end up outputting text that is invisible.

Obviously this would only happen for foreground and background combinations
where the colours were already fairly similar, (E.G. light grey against ever
so slightly darker grey), and ideally no sensible program is going to output
text like that.

But maybe something like a text-console based puzzle game might try to use all
of the available shades, and if we advertise 256 colour support then it's
reasonable for programs using it to assume that those colours are distinct.

Secondly, not all 8-bit displays are RGB.  Your change here:

> @@ -535,22 +567,26 @@ rasops_reconfig(struct rasops_info *ri, 
>  #endif
>  #if NRASOPS8 > 0
>  	case 8:
> +		ri->ri_caps |= WSSCREEN_256COL;
>  		rasops8_init(ri);
>  		break;
>  #endif

... sets WSSCREEN_256COL without checking RI_8BIT_IS_RGB, and if that flag bit
is not set then rasops_init_devcmap() will have only filled the first 16
elements of ri_devcmap[].

I haven't had chance to test the code on a non-rgb 8-bit display, but I'm
pretty sure it's going to break in that case, (unless I'm missing something).

Thirdly, 8-bit displays that _are_ RGB will be configured for 3 bits of red
and green, but only 2 bits for blue.  This makes half of the grey values have
a noticable yellow tint, which may well be why the anti-aliasing looks off
compared to higher colour depths.

Of course, 8-bit displays can still benefit from the direct selection of
palette colours 8 - 15, even without support for the full 256.

> Updated patch and the test script are attached.

In any case, many thanks for testing and adding 16 / 24 bit support!

I opened PR #59544 for the original patch back in July, by the way.