This is not finished but good enough for others to play with, enable with
options VCONS_DRAW_ASYNC
With this all drawing operations will be posted to a ring buffer instead
of being run directly, and run by a kernel thread. This avoids having to wait
for drawing operations to finish with the kernel lock held ( to a degree at
least ) and scrolling a (slow) framebuffer console should not disrupt other
operations anymore.
Problems:
- we need to switch back to synchronous operations when panicing or entering
ddb, also re-enable async drawing when leaving ddb
- there are still occasional glitches
tested on an SS20 with cg14 and cg6 for dumb and accelerated cases
requested by uwe@. These were wrong because they were receiving an
emulcookie yet they were accessops (thus having to receive an accesscookie).
Instead, just handle the WSDISPLAYIO_{GET,PUT}WSCHAR ioctls from the
driver's ioctl accessop.
As this reduces the amount of code needed to handle these operations to
two small functions in each driver, remove the WSDISPLAY_CHARFUNCS kernel
option.
Reviewed by, at least, uwe@ and macallan@. No objections in tech-kern@.
at the moment.
This includes the addition of two new wsdisplay ioctls, WSDISPLAY_{G,S}BORDER,
one to get the actual color and one to set it, respectively. Possible colors
match those defined by ANSI (and listed in wsdisplayvar.h).
It also adds two accessops to the underlying graphics device, getborder and
setborder, which mach their ioctl counterparts.
Two kernel options are added: WSDISPLAY_CUSTOM_BORDER, which enables the
ioctls described above (to customize the border color from userland after
boot), and WSDISPLAY_BORDER_COLOR, which sets the color at boot time.
The former is enabled by default on the GENERIC kernel, but not on INSTALL
(among others). The later is always commented out, leaving the usual black
border as a default.
wsconsctl is modified to allow accessing this value easily. For example,
'wsconsctl -d -w border=blue'.
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@.
not support a value (e.g., it's to be used as "options FOO" instead of
"options FOO=xxx"). options that take a value were converted to
defparam recently.
- minor whitespace & formatting cleanups
as config(8) will warn for value-less defparam options
- minor whitespace/formatting cleanup
- consolidate opt_tcp_recvspace.h and opt_tcp_sendspace.h into opt_tcp_space.h
many bugs have been fixed).
Changes:
The wskbd, wsmouse, and wsmux are now "sub-classes" of wsevsrc, which is
a source of ws events. This make the structure of those drivers a little
more uniform.
Many bug fixes involving adding and removing devices from muxes.
When a kernel is configured without wsmux there will now be none (unlike
before where you got a console mux anyway).
The kernel now compiles with all combinations of ws devices present.
by removing the "| wsdisplay" from the wsmux.c file declaration. This
will cause any kernel which includes wsdisplay but not wsmux explicitly
to fail to link, but at least those of us with multiple wsdisplays on
a single machine can build kernels again.
headaches.
Now console keyboard and display are connected at autoconfiguration time,
when the last of them is found. Other keyboards / displays remain
unconnected until a new ioctl (WSDISPLAYIO_SETKEYBOARD) is called.
-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
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?).
The graphics device driver passes a "default attribute" for normal text
output to the wscons framework. If the emulation module needs more
attributes (for different "renditions") it can allocate them via a
callback.
For now, only the "sun" emulation makes use of it.
