perry@piermont.com said:
> Martin Husemann <martin@duskware.de> writes:
> > since WSCOL_WHITE is not white at all

Uhm -- this already sounds like soap commercials:-)

Just to explain the concepts:
WSCOL_WHITE and the other colors are an _abstraction_. The device
driver is free to assign RGB values or whatever to it, within the
"allocattr" wsscreen callback. It should look more or less white
to the user.

There is also a wsscreen capability named "WSSCREEN_HILIT". Whether
this is offered or not is an implementation decision of the device
driver. (I count "rasops" as part of the device driver because it
is basically a helper library.) If a device driver advertizes
"WSSCREEN_HILIT", this means that it has a way to hilight a character,
even if it is already "WSCOL_WHITE". This highlighting is requested
by the "WSATTR_HILIT" flag to "allocattr". The upper layer ("wsemul")
should only request the HILIT attribute if the HILIT capability
is offered by the devive driver. The "wsemul" layer might have a
workaround for the case some text is to be highlighted. See the
vt100_selectattribute() function in wsemul_vt100_subr.c. In case
the screen supports colors, a red foreground is used instead.
(just an arbitrary choice)

So it is the driver's decision: Either it offers WSSCREEN_HILIT
capabilities, then it should keep a reserve to make white even whiter,
or it exhausts its energy to make the white as bright as possible
and gets suboptimal results for text which the terminal emulation
wants to hilight.
For pure b/w displays the latter is acceptable imho. Otherwise not.

best regards
Matthias