usable VGA console ("call ddb_vgapost")
-allow to switch from/to screens occupied by an X server if the graphics
device is console and in polling mode (ie DDB)
This together allows to get a DDB session on a VGA console if the
system crashed while X11 was running.
As long as the protocol to tell X servers about virtual screen switches
is as primitive as it is, it is unsafe to restart an X session afterwards.
So this is basically for crash analysis.
which are called somewhere in the middle of system suspend. Since the
X server accesses hardware directly it is outside our control whether
the devices it accesses are already/still suspended or not, so the only
way is to detach it before any device suspends and re-attach after
everything is awake again.
-For that, export a function ("wsdisplay_handlex" for now) which is
to be called from central suspend/resume code.
-The right way to handle the (normally impossible) case that the X
server is not detached on suspend is to return an error which should
abort the suspend process. pmf doesn't yet handle errors of device
suspend handlers, so as a temporary measure try to suspend anyway,
to get at least a text console.
-Improve error handling of X server attach/detach and maintain a flag
which tracks whether the X server is really active.
be using the "syncops" protocol) rather than doing a full switch
to virtual screen 1. The latter doesn't have the expected result if
the X server is running on screen 1, and is too much policy for inside
the kernel anyway.
Introduce a mutex+condvar to synchronize these operations, to replace
the spltty()/tsleep(). (for now only used by the new functions,
should be extended to the normal vt switching code)
system was before on resume. This is the second attempt and got more
complicated due to the async nature of VT_ACTIVE. After the initial
switch, check that we ended up on the first screen and if not, wait for
the switch to happen.
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@.
instead of a separate accessops entry. There is no need to introduce bloat
for the majority of drivers which don't implement this feature.
This should also resolve PR kern/33186 by Valeriy E. Ushakov.
* Add WSDISPLAY_TYPE_VESA for vesafb. While here, fix a typo in a comment.
* Add WSDISPLAYIO_SSPLASH and WSDISPLAYIO_SPROGRESS ioctls. The former
toggles the splash screen on and off, and the latter updates the progress
animation.
* Prevent more than one hw driver from claiming to be the console.
* In vcons, keep two pointers to the screen's vcons_data. This lets us
override the original (ie with null emulops during boot), and restore
them later on.
- Add a wsevent_inject function that atomically adds a set of events to an
event queue and change all code that directly messed with a queue to use it.
- Replace the WSEVENT_WAKEUP macro with a regular function.
- Make WSEVENT_QSIZE, PWSEVENT and splwsevent private definitions to
wsevent.c, instead of exposing them in the header file.
- Make the wsevent_init function take a process to attach to the queue,
instead of leaving this task to the caller (which always did it).
Reviewed 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@.
of struct wsdisplay_softc. Unused entries are NULL, and there were
a lot of places where we did not checked that the caller did not
requested an operation on a NULL entry.
While we are there, one bit of KNFification, and make return code more
consistent by always returning the same code (EINVAL) when a screen
number higer than the maximum is requested.
