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@.
which is very handy on a laptop to control EST through another program that
you don't necessarily want to run as root (in my case, gkrellm).
The option's name is EST_FREQ_USERWRITE, and is disabled by default.
to all GENERIC-like kernel config files where SYSV* options were already
present (commented out if the SYSV* options are commented out).
Fix lib/25897 and lib/25898.
Michael Eriksson posted to port-i386 on 20031102, with various
modifications by me to work in the new sysctl(9) framework.
The code is enabled with 'options ENHANCED_SPEEDSTEP', and if
the CPU supports EST the following sysctl(8) nodes appear
(with the values that a Dell Inspiron 8600 + WUXGA with a
1.4GHz Pentium M CPU supports):
machdep.est.cpu_brand = Intel(R) Pentium(R) M processor 1400MHz
machdep.est.frequency.target = 1400
machdep.est.frequency.current = 1400
machdep.est.frequency.available = 1400 1200 1000 800 600
If EST support isn't available, the "machdep.est" sysctl sub-MIB
is not created.
Once we have a more general "CPU frequency" control API we can
migrate this code to using that.
Thanks to Michael Erikkson for providing this code!
mycroft