martin@duskware.de said:
> Sure, that would be a complicated way to get a subset of the
> functionality we have now - I don't realy see a problem with the
> current definitions (and their use in arch/sparc64/conf/GENERIC32). 

There is the potential for array overflows at some points:
-In drivers which don't implement the LIGHT colors explicitely
 (as vga),
-and in case a LIGHT colour gets used together with WSATTR_HILIT
 in rasops_allocattr_color().

Fine only if you watch out carefully what gets into the config file.
I'd say having 2 ways of getting a color lighter makes things more
complicated. I'd avoid it.

> I'd like to suggest the attached patch - most drivers (all rasops
> based ones at least) seem to advertise (and properly implement)
> WSATTR_REVERSE even for colour displays. So I'd suggest to try that
> first

This looks fine to me. I have to admit that I never did more than basic
tests with wsemul_sun because wsemul_vt100 looks that much nicer.

One could argue whether it makes sense to offer REVERSE capability
if the upper layer can just reverse the fg/bg arguments. But the
implementation is _that_ cheap that, well, documenting or enforcing
such a restriction would look ridiculous.

Btw, the "default attributes" passed from the display driver to
wsdisplay should go one day. There are historical reasons that
this exists -- in particular the fact that DEC Alphas (where
the wscons framework originates from) with certain display adapters
used white-on-blue for console output.
This conflicts with terminal emulation semantics (at least with vt100),
and generally it would be cleaner to deal with the (high-level)
appearance at wsemul level only.
This would mean that wsemul_*_init code would have to fetch its
attributes explicitely, even in early console initialization.
I don't have time to implement this in the next couple of weeks
however.

best regards
Matthias