Two new ioctls are added to the wsdisplay device, named WSDISPLAY_GMSGATTRS
and WSDISPLAY_SMSGATTRS, used to retrieve the actual values and set them,
respectively (the name, if you are wondering, comes from "message attributes").
A new emulop is added to the underlying display driver (only vga, for now)
which sets the new attribute for the whole screen, without having to clear
it. This is optional, which means that this also works with other drivers
that don't have this new operation.
Five new kernel options have been added, although only documented in
i386 kernels (for now):
- WSDISPLAY_CUSTOM_OUTPUT, which enables the ioctls described above to
change the colors dynamically from userland. This is enabled by default
in the GENERIC kernel (as well as others) but disabled on all INSTALL*
kernels (as this feature is useless there).
- WS_DEFAULT_COLATTR, WS_DEFAULT_MONOATTR, WS_DEFAULT_BG and WS_DEFAULT_FG,
which specify the default colors for the console at boot time. These have
the same meaning as the (already existing) WS_KERNEL_* variables.
wsconsctl is modified to add msg.default.{attrs,bg,fg} and
msg.kernel.{attrs,bg,fg} to the display part, so that colors can be changed
after boot.
Tested on NetBSD/i386 with vga (and vga in mono mode), and on NetBSD/mac68k.
No objections in tech-kern@.
current attribute, but has all non-color flags turned off. Use this when
doing erasure, as this allows us to optimize repainting in curses.
XXX The way the default attribute is handled is totally bogus and needs to
be fixed.
-display DEC special graphics and DEC technical characters as far as
possible
-implement the font switching controls (need documentation!)
-behave well if double-width characters are requested
-simplify the state machine: store CSI command modifiers in variables
instead of dedicating own states to each of them
to take a single character at a time, where the character is an "int" now.
The old interface (took a string) was never called with more than 1
char to print, and the "int" allows us to handle charsets cleanly.
It should be able to parse escape sequences up to VT300, but not everything
is implemented. Most notably, there is no font handling - all displayable
characters are handed to the graphics driver. To solve this, a serious
interface change to the graphics driver is needed (Unicode?).
jmmv