Subject: Re: CVS commit: src/sys/dev/wscons
To: Martin Husemann <firstname.lastname@example.org>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
Date: 05/24/2005 22:07:30
> 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
-and in case a LIGHT colour gets used together with WSATTR_HILIT
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
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