it had claimed while acting as the initial console device. This allows
(for example) vga to be the initial console, and an accelerated
framebuffer driver to take over later.
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@.
to the screen on which they are being called. The driver cannot guess
this by itself but it is needed to implement, at least, the getwschar and
putwschar functions in the correct place. There are no functional changes
yet.
Tested on i386 (vga, vga_raster, machfb, vesafb), macppc and sparc64.
Suggested and reviewed by macallan@.
registers after switching to a VESA linear framebuffer mode is not
guaranteed to work. This should fix the majority of the problems people
have been experiencing with vesafb.
XXX: Still doesn't fix the assertion in wscons with options DIAGNOSTIC.
WSDISPLAY_BORDER_COLOR option, broken by a last-minute change.
Pointed out by xtraeme@.
Also back out the previous change by dogcow@, which was an attempt
to fix kernel builds that didn't define WSDISPLAY_CUSTOM_BORDER;
shouldn't be needed now. (Problem also introduced by the same
last-minute change; sorry).
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@.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
to use generic VGA driver(s):
- Allow VGA drivers to use wsfont instead of builtin font.
- Add vga_reset() function, which will be called from MD consinit(),
to put VGA into text mode. This function is enabled by options VGA_RESET.
-treat the builtin font like any other font at runtime
-for that, copy it to malloc()'d memory during attach()
-in early console initialization, if we have to consider a broken card
(VGA_CONSOLE_ATI_BROKEN_FONTSEL), copy the builtin font to another
location in font ram; the attach() code will do the rest
put the "quirk" code into effect again
found on many (all?) of PCI-based ATI graphics cards. It is fully optional
and can be enabled by adding `options VGA_CONSOLE_ATI_BROKEN_FONTSEL'
to config file.
- Temporarily remove `quirk' mechanism. Similar code already exists
in pci_quirks.c.
-Don't assume fonts to start with character 0, load at the
right offset. Now we can use eg wsfont/bold8x16.h which
starts with chr(1).
-Don't touch the hardware if a font is set for a screen which is
not active.
make the number of available font slots variable,
set up a "quirk" mechanism to tell the generic vga code about crippled
VGA adapters which ignore the "fontsel" TS register,
initiate the quirk table with an ATI chip which happened to be on a board
I tested with.
Afaik quite a number of ATI chips suffers from the "loaded fonts don't
work" problem - these should be added.
Bad side effect of my change: The builtin font will be kicked out
always if a VGA_CONSOLE_SCREENTYPE is specified which needs a loaded
font. In early console initialization, we don't know much about the
graphics card, so we have to assume the worst (ie ATI:-).
dyoung