sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

Remove sparc64 kernel support

Remove all sparc64 specific files
Remove all sparc64 ifdefs
Removee indireeect sparc64 ifdefs

syscons: drop keyboard index from softc

Analysis seems to reveal that sc->keyboard >= 0 implies sc->kbd != NULL and
there's no such scenario where sc->kbd is set (and theoretically used to
rebuild s

syscons: drop keyboard index from softc

Analysis seems to reveal that sc->keyboard >= 0 implies sc->kbd != NULL and
there's no such scenario where sc->kbd is set (and theoretically used to
rebuild sc->keyboard) with the keyboard unavailable.

Drop the index softc. The index is only explicitly needed in few places, in
which case we can just as easily grab it from sc->kbd. There's no need for
keeping sc->kbd and sc->keyboard in sync when it can be readily accomplished
with just the former.

show more ...

Fix the dumb and sc terminal emulators to compile and work.

First remove ifdefs of the unsupported option SC_DUMB_TERMINAL which
prevented building using both in the same kernel and broke regression

Fix the dumb and sc terminal emulators to compile and work.

First remove ifdefs of the unsupported option SC_DUMB_TERMINAL which
prevented building using both in the same kernel and broke regression
tests. This option will be replaced by per-emulator supported options.

The dumb emulator rotted with KSE in r83366, but usually compiled since
it is ifdefed to nothing unless SC_DUMB_TERMINAL is defined. The type
of an unused function parameter changed.

Both emulators rotted when 2 new methods were added while the emulators
were removed. Only null methods are needed, but null function pointers
give panics instead.

The wildcard in the default for the unsupported option SC_DFLT_TERM
never really worked. It tends to prefer the dumb emulator when multiple
emulators are configured. Change it to prefer scteken for compatibility.

show more ...

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...

Support setting the colors of cursors for the VGA renderer.

Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolo

Support setting the colors of cursors for the VGA renderer.

Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]

The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.

Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.

The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.

show more ...

Rename curr_curs_attr to base_curr_attr. The actual current cursor
attribute field is curs_attr. The base field holds user data translated
in a reversible way and is needed because current field ho

Rename curr_curs_attr to base_curr_attr. The actual current cursor
attribute field is curs_attr. The base field holds user data translated
in a reversible way and is needed because current field holds this in
an irreversible way for efficiency.

Factor out some common code for the reversible translation. This is
slightly simpler now, and much easier to expand.

Translate the magic flags value -1 to a single control flag internally
up front so other flags can be trusted later. This can be used for the
relevant ioctl() too.

Remove CONS_CURSOR_FLAGS which contained all the control flags. It was
unused and not useful. After adding more flags, there will be tests on
a couple at a time but never on them all. This API should have used this
to disallow unknown flags.

show more ...

Use better hard-coded defaults for the cursor shape, and remove nearby
redundant initializations.

Hard-code base = 0, height = (approx. 1/8 of the boot-time font height)
in all cases, and remove the

Use better hard-coded defaults for the cursor shape, and remove nearby
redundant initializations.

Hard-code base = 0, height = (approx. 1/8 of the boot-time font height)
in all cases, and remove the BIOS/MD support for setting these values.
This asks for an underline cursor sized for the boot-time font instead
of various less hard-coded but worse values. I used that think that
the x86 BIOS always gave the same values as the above hard-coding, but
on 1 of my systems it gives the wrong value of base = 1.

The remaining BIOS fields are shift_state and bell_pitch. These are now
consistently not explicitly reinitialized to 0. All sc_get_bios_value()
functions except x86's are now empty, and the only useful thing that x86
returns is shift_state. This really belongs in atkbdc, but heavier
use of the BIOS to read the more useful typematic rate has been removed
there. fb still makes much heavier use of the BIOS.

show more ...

Add many bitmaps (now there are 13) for mouse cursors and logic to try
to choose the best one.

The old 9x13 cursor was was sort of correct for CGA 640x200 text mode,
but distorted for all other mode

Add many bitmaps (now there are 13) for mouse cursors and logic to try
to choose the best one.

The old 9x13 cursor was was sort of correct for CGA 640x200 text mode,
but distorted for all other modes. This mode is still available on
all systems with VGA, but stopped being useful in ~1985. It has very
unsquare pixels with an aspect ratio of 240:100 on 4:3 monitors. On
16:9 monitors, the unsquareness in this mode is reduced to only 180:100
iff the monitor stretches the pixels to the full screen.

Newer modes and systems have smaller distortions, but with many more
variations. Square pixels first became common with VGA 640x480 mode
on 4:3 monitors. However, standard VGA text mode also has 9-bit wide
characters and only 25 lines, so it has 720x400 pixels. This has
unsquare pixels with an aspect ratio of 135:100 on 4:3 monitors. On
16:9 monitors, it gives almost-square pixels with an aspect ration of
101:100 iff the monitor stretches, but in modes that were square on
4:3 monitors square similar monitor stretching breaks the squareness.

Guess the physical aspect ratio using heuristics. The old version of
X that I use is further from doing this using info from PnP monitors
that is unavailable in syscons (X doesn't understand if the monitor
is doing stretching and doesn't even understand how its its own mode
changes affect the pixel size). Monitors with aspect ratio control
should be configured to _not_ stretch 4:3 modes to 16:9. Otherwise,
use the machdep.vga_aspect_scale sysctl to compensate. Only 1 of my
4 monitors/laptops requires this. It always stretches to 16:9.

The mouse data has new aspect ratio fields for selecting the best
cursor and a new name field for display in debugging messages.

Selecting the mouse cursor is now a slow operation so it is not done
for every drawing of the cursor. To avoid a new initialization method,
it is done whenever the text cursor is set or changed. Also remove
dead code in settings of text cursors.

Use larger mouse cursors (sometimes the full 10x16 one) for 8x8 fonts
in cases where this works better (mostly in graphics mode).

show more ...

When the character width is 9, remove vertical lines in the mouse cursor
corresponding to the gaps between characters. This fixes distortion
of the cursor due to expanding it across the gaps.

Again

When the character width is 9, remove vertical lines in the mouse cursor
corresponding to the gaps between characters. This fixes distortion
of the cursor due to expanding it across the gaps.

Again for character width 9, when the cursor characters are not in the
graphics range (0xb0-0xdf), the gaps were always there (filled in the
background color for the previous char). They still look strange, but
don't cause distortion. When the cursor characters are in the graphics
range, the gaps are filled by repeating the previous line. This gives
distortion with cilia. Removing vertical lines reduces the distortion
to vertical cilia.

Move the default for the cursor characters out of the graphics range.
With character width 9, this gives gaps instead of distortion and
other problems. With character width 8, it just fixes a smaller set
of other problems. Some distortion and other problems can be recovered
using vidcontrol -M. Presumably the default was to fill the gaps
intentionally, but it is much better to leave gaps. The gaps can even
be considered as a feature for text processing -- they give sub-pointers
to character boundaries. The other problems are: (1) with character
width 9, characters near the cursor are moved into the graphics range
and thus distorted if any of their 8th bits is set; (2) conflicts with
national characters in the graphics range.

The default range for the graphics cursor characters is now 8-11. This
doesn't conflict with anything, since the glyphs for the characters in
this range are unreachable.

Use the 10x16 mouse cursor in text mode too (if the font size is >= 14).

When the character width is 9, removal of 1 or 2 vertical lines makes
10x16 cursor no wider than the 9x13 one usually was. We could even
handle cursors 1 pixel wider in 2 character cells and gaps without
more clipping than given by the gaps (the worst case is 1 pixel in the
left cell, 1 removed in the middle gap, 8 in the right cell and 1
removed in the right gap. The pixel in the right gap is removed so
it doesn't matter if it is in the font).

When the character width is 8, we now clip the 10-wide cursor by 1
pixel in the worst case. This clipping is usually invisible since it
is of the border and and the border usually merges with the background
so is invisible. There should be an option to use reverse video to
highlight the border and its tip instead of the interior (graphics
mode can do better using separate colors). This needs the 9x13 cursor
again.

Ideas from: ache (especially about the bad default character range)

show more ...

Fix removal of the keyboard cursor image in text mode, especially
in the vga renderer. Removal used stale attributes and didn't try to
merge with the current attribute for cut marking, so special re

Fix removal of the keyboard cursor image in text mode, especially
in the vga renderer. Removal used stale attributes and didn't try to
merge with the current attribute for cut marking, so special rendering
of cut marking was lost in many cases. The gfb renderer is too broken
to support special rendering of cut marking at all, so this change is
supposed to be just a style fix for it. Remove all traces of the
saveunder method which was used to implement this bug.

Fix drawing of the cursor image in text mode, only in the vga
renderer. This used a stale attribute from the frame buffer instead
of from the saveunder, but did merge with the current attribute for
cut marking so it caused less obvious bugs (subtle misrendering for
the character under the cursor).

The saveunder method may be good in simpler drivers, but in syscons
the 'under' is already saved in a better way in the vtb. Just redraw
it from there, with visible complications for cut marking and
invisible complications for mouse cursors. Almost all drawing
requests are passed a flag 'flip' which currently means to flip to
reverse video for characters in the cut marking region, but should
mean that the the characters are in the cut marking regions so should
be rendered specially, preferably using something better than reverse
video. The gfb renderer always ignores this flag. The vga renderer
ignored it for removal of the text cursor -- the saveunder gave the
stale rendering at the time the cursor was drawn. Mouse cursors need
even more complicated methods. They are handled by drawing them last
and removing them first. Removing them usually redraws many other
characters with the correct cut marking (but transiently loses the
keyboard cursor, which is redrawn soon). This tended to hide the
saveunder bug for forward motions of the keyboard cursor. But slow
backward motions of the keyboard cursor always lost the cut marking,
and fast backwards motions lost in for about 4 in every 5 characters,
depending on races with the scrn_update() timeout handler. This is
because the forward motions are usually into the region redrawn for
the mouse cursor, while backwards motions rarely are.

Text cursor drawing in the vga renderer used also used a
possibly-stale copy of the character and its attribute. The vga
render has the "optimization" of sometimes reading characters from the
screen instead of from the vtb (this was not so good even in 1990 when
main memory was only a few times faster than video RAM). Due to care
in update orders, the character is never stale, but its attribute
might be (just the cut marking part, again due to care in order).

gfb doesn't have the scp->scr pointer used for the "optimization", and
vga only uses this pointer for text mode. So most cases have to
refresh from the vtb, and we can be sure that the ordering of vtb
updates and drawing is as required for this to work.

show more ...

The switch to kernel terminal context needs to update more than the cursor
position. Especially the screen size, and potentially everything except
the input state and attributes. Do this by changin

The switch to kernel terminal context needs to update more than the cursor
position. Especially the screen size, and potentially everything except
the input state and attributes. Do this by changing the cursor position
setting method to a general syncing method.

Use proper constructors instead of copying to create kernel terminal
contexts. We really want clones and not new instances, but there is
no method for cloning and there is nothing in the active instance that
needs to be cloned exactly.

Add proper destructors for kernel terminal contexts. I doubt that the
destructor code has every been reached, but if it was then it leaked the
memory of the clones.

Remove freeing of statically allocated memory for the non-kernel terminal
context for the same terminal as the kernel. This is in the nearly
unreachable code. This used to not happen because delicate context
swapping made the user context use the dynamic memory and kernel
context the static memory. I didn't restore this swapping since it
would have been unnatural to have all kernel contexts except 1 dynamic.

The constructor for terminal context has bad layering for reasons
related to the bug. It has to return static memory early before
malloc() works. Callers also can't allocate memory until after the
first constructor selects an emulator and tells upper layers the size
of its context. After that, the cloning hack required the cloning
code to allocate the memory, but for all other constructors it would
be better for the terminal layer to allocate and deallocate the
memory in all cases.

Zero the memory when allocating terminal contexts dynamically.

show more ...

Restore switching to a separate kernel terminal "input" state and extend
it to a separate state for each CPU.

Terminal "input" is user or kernel output. Its state includes the current
parser state

Restore switching to a separate kernel terminal "input" state and extend
it to a separate state for each CPU.

Terminal "input" is user or kernel output. Its state includes the current
parser state for escape sequences and multi-byte characters, and some
results of previous parsing (mainly attributes), and in teken the cursor
position, but not completed output. This state must be switched for kernel
output since the kernel can preempt anything, including itself, and this
must not affect the preempted state more than necessary. Since vty0 is
shared, it is necessary to affect the frame buffer and cursor position and
history, but escape sequences must not be affected and attributes for
further output must not be affected.

This used to work. The syscons terminal state contained mainly the parser
state for escape sequences and attributes, but not the cursor position,
and was switched. This was first broken by SMP and/or preemptive kernels.
Then there should really be a separate state for each thread, and one more
for ddb, or locking to prevent preemption. Serialization of printf() helps.
But it is arcane that full syscons escape sequences mostly work in kernel
printf(), and I have never seen them used except by me to test this fix.
They worked perfectly except for the races, since "input" from the kernel
was not special in any way.

This was broken to use teken. The general switch was removed, and the
kernel normal attribute was switched specially. The kernel reverse
attribute (config option SC_CONS_REVERSE_ATTR) became unused, and is
still unusable because teken doesn't support default reverse attributes
(it used to only be used via the ANSI escape sequence to set reverse
video).

The only new difficulty for using teken seems to be that the cursor
position is in the "input" state, so it must be updated in the active
input state for each half of the switch. Do this to complete the
restoration.

The per-CPU state is mainly to make per-CPU coloring work cleanly, at
a cost of some space. Each CPU gets its own full set of attribute
(not just the current attribute) maintained in the usual way. This
also reduces races from unserialized printf()s. However, this gives
races for serialized printf()s that otherwise have none. Nothing
prevents the CPU doing the a printf() changing in the middle of an
escape sequence.

show more ...

Add a scteken_set_cursor() (sc to teken) method and use it to fix
some cases of initialization and resetting of the teken cursor position.
(This bad name is consistent with others, but it is too easy

Add a scteken_set_cursor() (sc to teken) method and use it to fix
some cases of initialization and resetting of the teken cursor position.
(This bad name is consistent with others, but it is too easy to confuse
with scteken_cursor() which goes in the opposite direction.)

The following cases were broken:
- for booting without a syscons console, the teken and sc positions for
ttyv0 were (0, 0), but are supposed to be somewhere in the middle of
the screen (after carefully preserved BIOS and loader messages) (at
least if there is no mode switch that loses the messages).
- after mode switches, the screen is cleared and the cursor is supposed to
be moved to (0, 0), but it was only moved there for sc.

The following case was hacked to work:
- for booting with a syscons console, it was arranged that scteken_init()
for the console could see a nonzero cursor position and adjust, although
this broke the sc seeing it in the non-console case above.

show more ...

Colorize syscons kernel console output according to a table indexed
by the CPU number.

This was originally for debugging near-deadlock conditions where
multiple CPUs either deadlock or scramble each

Colorize syscons kernel console output according to a table indexed
by the CPU number.

This was originally for debugging near-deadlock conditions where
multiple CPUs either deadlock or scramble each other's output trying
to report the problem, but I found it interesting and sometimes
useful for ordinary kernel messages. Ordinary kernel messages
shouldn't be interleaved, but if they are then the colorization
makes them readable even if the interleaving is for every character
(provided the CPU printing each message doesn't change).

The default colors are 8-15 starting at 15 (bright white on black)
for CPU 0 and repeating every 8 CPUs. This works best with 8 CPUs.
Non-bright colors and nonzero background colors need special
configuration to avoid unreadable and ugly combinations so are not
configured by default. The next bright color after 15 is 8 (bright
black = dark gray) is not very readable but is the only other color
used with 2 CPUs. After that the next bright color is 9 (bright
blue) which is not much brighter than bright black, but is used with
3+ CPUs. Other bright colors are brighter.

Colorization is configured by default so that it gets tested. It can
only be turned off by configuring SC_KERNEL_CONS_ATTR to anything other
than FG_WHITE. After booting, all colors can be changed using the
syscons.kattr sysctl. This is a SYSCTL_OPAQUE, and no utility is
provided to change it (sysctl only displays it).

The default colors work in all VGA modes that I could test. In 2-color
graphics modes, all 8 bright colors are displayed as bright white, so
the colorization has no effect, but anything with a nonzero background
gives white on white unless the foreground is zero. I don't have an
mono or VGA grayscale hardware to test on. Support for mono mode seems
to have never worked right in syscons (I think bright white gives white
underline with either bold or bright), but VGA grayscale should work
better than 2-color graphics.

show more ...

Remove pc98 support completely.
I thank all developers and contributors for pc98.

Relnotes: yes

The log message for the previous commit didn't mention the most the
important detail that sc_cngetc() now opens and closes the keyboard
on every call again. This was moved from sc_cngetc() to scn_cn

The log message for the previous commit didn't mention the most the
important detail that sc_cngetc() now opens and closes the keyboard
on every call again. This was moved from sc_cngetc() to scn_cngrab/
ungrab() in r228644, but the change wasn't quite complete. After
fixes for nesting in kbdd_poll() in ukbd and kbdmux, these opens
and closes should have no significant effect if done while grabbed.
They fix unusual cases when cngetc() is called while not grabbed.

This commit is the main fix for screen locking in sc_cnputc():
detect deadlock or likely-deadlock and handle it by buffering the
output atomically and printing it later if the deadlock condition
clears (and sc_cnputc() is called).

The most common deadlock is when the screen lock is held by ourself.
Then it would be safe to acquire the lock recursively if the console
driver is calling printf() in a safe context, but we don't know when
that is. It is not safe to ignore the lock even in kdb or panic mode.
But ignore it in panic mode. The only other known case of deadlock
is when another thread holds the lock but is running on a stopped CPU.
Detect that case approximately by using trylock and retrying for 1000
usec. On a 4 GHz CPU, 100 usec is almost long enough -- screen switches
take slightly longer than that. Not retrying at all is good enough
except for stress tests, and planned future versions will extend the
timeout so that the stress tests work better.

To see the behaviour when deadlock is detected, single step through
sctty_outwakeup() (or sc_puts() to start with deadlock). Another
(serial) console is needed to the buffered-only output, but the
keyboard works in this context to continue or step out of the
deadlocked region. The buffer is not large enough to hold all the
output for this.

show more ...

Add some locking to sc_cngetc().

Keyboard input needs Giant locking, and that is not possible to do
correctly here. Use mtx_trylock() and proceed unlocked as before if
we can't acquire Giant (non-r

Add some locking to sc_cngetc().

Keyboard input needs Giant locking, and that is not possible to do
correctly here. Use mtx_trylock() and proceed unlocked as before if
we can't acquire Giant (non-recursively), except in kdb mode don't
even try to acquire Giant. Everything here is a hack, but it often
works. Even if mtx_trylock() succeeds, this might be a LOR.

Keyboard input also needs screen locking, to handle screen updates
and switches. Add this, using the same simplistic screen locking
as for sc_cnputc().

Giant must be acquired before the screen lock, and the screen lock
must be dropped when calling the keyboard driver (else it would get a
harmless LOR if it tries to acquire Giant). It was intended that sc
cn open/close hide the locking calls, and they do for i/o functions
functions except for this complication.

Non-console keyboard input is still only Giant-locked, with screen
locking in some called functions. This is correct for the keyboard
parts only.

When Giant cannot be acquired properly, atkbd and kbdmux tend to race
and work (they assume that the caller acquired Giant properly and don't
try to acquire it again or check that it has been acquired, and the
races rarely matter), while ukbd tends to deadlock or panic (since it
does the opposite, and has other usb threads to deadlock with).

The keyboard (Giant) locking here does very little, but the screen
locking completes screen locking for console mode except for not
detecting or handling deadlock.

show more ...

Less-quick fix for locking fixes in r172250. r172250 added a second
syscons spinlock for the output routine alone. It is better to extend
the coverage of the first syscons spinlock added in r162285

Less-quick fix for locking fixes in r172250. r172250 added a second
syscons spinlock for the output routine alone. It is better to extend
the coverage of the first syscons spinlock added in r162285. 2 locks
might work with complicated juggling, but no juggling was done. What
the 2 locks actually did was to cover some of the missing locking in
each other and deadlock less often against each other than a single
lock with larger coverage would against itself. Races are preferable
to deadlocks here, but 2 locks are still worse since they are harder
to understand and fix.

Prefer deadlocks to races and merge the second lock into the first one.

Extend the scope of the spinlocking to all of sc_cnputc() instead of
just the sc_puts() part. This further prefers deadlocks to races.

Extend the kdb_active hack from sc_puts() internals for the second lock
to all spinlocking. This reduces deadlocks much more than the other
changes increases them. The s/p,10* test in ddb gets much further now.
Hide this detail in the SC_VIDEO_LOCK() macro. Add namespace pollution
in 1 nested #include and reduce namespace pollution in other nested
#includes to pay for this.

Move the first lock higher in the witness order. The second lock was
unnaturally low and the first lock was unnaturally high. The second
lock had to be above "sleepq chain" and/or "callout" to avoid spurious
LORs for visual bells in sc_puts(). Other console driver locks are
already even higher (but not adjacent like they should be) except when
they are missing from the table. Audio bells also benefit from the
syscons lock being high so that audio mutexes have chance of being
lower. Otherwise, console drviver locks should be as low as possible.
Non-spurious LORs now occur if the bell code calls printf() or is
interrupted (perhaps by an NMI) and the interrupt handler calls
printf(). Previous commits turned off many bells in console i/o but
missed ones done by the teken layer.

show more ...

Flesh out the state and flags args to sccnopen(). Set state flags to
indicate (potentially partial) success of the open. Use these to
decide what to close in sccnclose(). Only grab/ungrab use open

Flesh out the state and flags args to sccnopen(). Set state flags to
indicate (potentially partial) success of the open. Use these to
decide what to close in sccnclose(). Only grab/ungrab use open/close
so far.

Add a per-sc variable to count successful keyboard opens and use
this instead of the grab count to decide if the keyboad state has
been switched.

Start fixing the locking by using atomic ops for the most important
counter -- the grab level one. Other racy counting will eventually
be fixed by normal mutex or kdb locking in most cases.

Use a 2-entry per-sc stack of states for grabbing. 2 is just enough
to debug grabbing, e.g., for gets(). gets() grabs once and might not
be able to do a full (or any) state switch. ddb grabs again and has
a better chance of doing a full state switch and needs a place to
stack the previous state. For more than 3 levels, grabbing just
changes the count. Console drivers should try to switch on every i/o
in case lower levels of nesting failed to switch but the current level
succeeds, but then the switch (back) must be completed on every i/o
and this flaps the state unless the switch is null. The main point
of grabbing is to make it null quite often. Syscons grabbing also
does a carefully chosen screen focus that is not done on every i/o.

Add a large comment about grabbing.

Restore some small lost comments.

show more ...

Fix restoring the kbd_mode part of the keyboard state in grab/ungrab.
Simply change the mode to K_XLATE using a local variable and use the
grab level as a flag to tell screen switches not to change i

Fix restoring the kbd_mode part of the keyboard state in grab/ungrab.
Simply change the mode to K_XLATE using a local variable and use the
grab level as a flag to tell screen switches not to change it again,
so that we don't need to switch scp->kbd_mode. We did the latter,
but didn't have the complications to update the keyboard mode switch
for every screen switch. sc->kbd_mode remains at its user setting
for all scp's and ungrabbing restores to it.

show more ...

[Oops, the previous commit was missing the update to syscons.h.]

Like scr_lock, the grab count needs to be per-physical-device to work.

This bug corrupted the grab count on both vtys if the ungrabb

[Oops, the previous commit was missing the update to syscons.h.]

Like scr_lock, the grab count needs to be per-physical-device to work.

This bug corrupted the grab count on both vtys if the ungrabbed vty is
different from the console, and failed to restore the keyboard state
on the ungrabbed vty, but not restoring it usually left the keyboard
mode part of the keyboard state uncorrupted at 1 (K_XLATE), while
after this fix the keyboard mode part is usually corrupted to 0 (K_RAW).

While here, rename the grab count from grabbed to grab_level.

show more ...

Quick fix for locking fixes in r172250. The lock added there was per-
virtual-device, but needs to be per-physical-device so that it protects
shared data. Usually, scp->sc->write_in_progress got co

Quick fix for locking fixes in r172250. The lock added there was per-
virtual-device, but needs to be per-physical-device so that it protects
shared data. Usually, scp->sc->write_in_progress got corrupted first
and further corruption was limited when this variable was left at nonzero
with no write in progress.

Attempt to fix missing lock destruction in r162285. Put it with the
lock destruction for r172250 after moving the latter. Both might be
unreachable.

To demonstrate the bug, find a buggy syscall or sysctl that calls
printf(9) and run this often. Run hd /dev/zero >/dev/ttyvN for any
N != 0. The console spam goes to ttyv0 and the non-console spam goes
to ttyvN, so the lock provided no protection (but it helped for
N == 0).

show more ...

Fix comment introduced in r262480: it's 1920x1200, not 1980x1200.

PR: kern/180558
MFC after: 5 days

Increase maximum number of columns to support 1980x1200 displays.

In my specific case, this fixes the problem of my PowerMac G5 displaying a
4:3 console on a 16:10 display with black bars on the lef

Increase maximum number of columns to support 1980x1200 displays.

In my specific case, this fixes the problem of my PowerMac G5 displaying a
4:3 console on a 16:10 display with black bars on the left and right.

PR: kern/180558
Reviewed by: nwhitehorn
MFC after: 5 days

show more ...