On Tue, May 24, 2005 at 10:07:30PM +0200, Matthias Drochner wrote:
> 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().

I would expect the drivers to mask colour indices to their
cmap size.

> 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.

Ok - the easiest way to achive what you suggested (or what I understood
that you suggested) would be this patch. I don't realy like it,
looks like a hack to me. Maybe I misunderstood your suggestion.

Index: rasops.c
===================================================================
RCS file: /cvsroot/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.48
diff -u -r1.48 rasops.c
--- rasops.c    2 May 2005 00:00:33 -0000       1.48
+++ rasops.c    24 May 2005 20:33:41 -0000
@@ -409,6 +409,8 @@
                bg = WSCOL_BLACK;
 #endif
        }
+       if (bg == WSCOL_WHITE)
+               bg += 8;        /* use real white for background */
 
        if ((flg & WSATTR_REVERSE) != 0) {
                swap = fg;


We could also move the special treatment to rasops_unpack_attr, but that is
not always used - multiple places just shift & mask the colours out of the
attr.

> 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.

I agree. I'm not sure everyone else will, though.

Martin