Commit Graph

824 Commits

Author SHA1 Message Date
Bruce Evans
8bae6e480d Fix removal of mouse image by the vga planar renderer in the right border
in unusual cases.  Optimize and significantly clean up removal in this
renderer.  Optimize removal in the vga direct renderer.

Removal only needs to be done in the border (the part with pixels) in
both cases.  The planar renderer used the condition scp->xoff > 0 to
test whether a right border exists.  This actually tests for a left
border, and when the total horizontal border is 8 pixels, rounding gives
only a right border.  This was the unusual broken case.  An example
is easy to configure using something like "vidcontrol -f 8x16 iso-8x16
-g 79x25 MODE_27".

Optimize the planar case a little by only removing 9x13 active pixels
out of 16x16.  Optimize it a lot by not doing anything if there is no
overlap with the border.  Don't unroll the main loop or hard-code so
many assumptions about font sizes in it.  On my Haswell system, graphics
memory and i/o accesses takes about 520 cycles each so optimizations from
unrolling are in the noise.

Optimize the direct case to not do anything if there is no overlap with
the border.  Do a sanity check on the saveunder's coordinates.  This
requires a previous change to pass non-rounded coordinates.
2017-04-12 18:52:06 +00:00
Bruce Evans
ac07ac7c74 Trival style fix to previous commit to add this detail.
The previous commit also fixed the coordinates passed to the mouse
removal renderer.  The coordinates were rounded down to a character
boundary, and thus essentially unusable.  The renderer had to keep
track of the previous position, or clear a larger area.  The latter
is only safe in the border, which is all that needs special handling
anyway.

I think no renderer depends on the bug.  They have the following
handling:
- gfb sparc64: this seems to assume non-rounded coordinates
- gfb other: does nothing (seems to be missing border handling)
- vga text: does nothing (doesn't need border handling)
- vga planar: clears extras in the border, with some bugs.  The fixes
  will use the precise coordinates to optimize.
- vga direct: clears at the previous position with no check that it
  is active, and clears everything.  Checking finds this bug.
- others: are there any?
2017-04-12 17:38:00 +00:00
Bruce Evans
accdee8d46 Fix removing of the mouse image in vga planar mode with 8x8 fonts, and
reduce hard-coded assumptions on font sizes so that the cursor size
can be more independent of the font size.  Moving the mouse in the
buggy mode left trails of garbage.

The mouse cursor currently has size 9x13 in all modes.  This can occupy
2x3 character cells with 8x8 fonts, but the algorithm was hard-coded
for only 2x2 character cells.  Rearrange to hard-code only a maximum
cursor size (now 10x16) and to not hard-code in the logic.  The number
of cells needed is now over-estimated in some cases.

2x3 character cells should also be used in text mode with 8x8 fonts
(except with large pixels, the cursor size should be reduced), but
hard-coding for 2x2 in the implementation makes it not very easy to
expand, and it practice it shifts out bits to reduce to 2x2.

In graphics modes, expansion is easier and there is no shifting out
for 9x13 cursors (but 9 is a limit for hard-coding for 2 8-bit VGA
cells wide).  A previous commit removed the same buggy hard-coding for
removal at a lower level in planar mode.  Another previous commit fixed
the much larger code for lower-level removal in direct mode; this is
independent of the font size so worked for 8x8 fonts.  Text mode always
depended on the higher-level removal here, and always worked since
everything was hard-coded consistently for 2x2 character cells.
2017-04-12 17:06:24 +00:00
Bruce Evans
af032a9dec Fix clobbering of the default attribute and the screen position in
scteken_init().  Move the internals of scteken_sync() into a local
function to help do this.

scteken_init() reset or adjusted the default attribute and screen
position at least 3 and 5 times, respectively.  Warm init shouldn't
do any more than reset the "input" state.
  (scterm-sc.c (which still works after minor editing), only resets
  the escape state and the saved cursor position, and then does a
  nearly-null sync of the current color.)

This mainly broke mode changes, and was most noticeable when the
background color is not teken's default (usually black).  Then the
screen gets cleared in the wrong color.  vidcontrol restores the
default normal attribute and tries to restore the default reverse
attribute.  vidcontrol doesn't clear the screen again after restoring
the attribute(s), and it is too late to do it there without flicker.
Now the default normal attribute is restored before the change affects
the rendering.

When the foreground color is not teken's default, clearing with the
wrong attributes gave strange cursor colors for some cursor types.

The default reverse attribute is not restored since it is unsupported.

2/3 of the clobbering was from 2 resetting window resizing calls.  The
second one is needed to restore the size, but must not reset.  Window
resizing also sanitizes the cursor position, and after the main reset
resets the window size, the cursor row would often be adjusted from
24 to 23 if it were not already reset to 0.  scteken_sync() is good
for restoring the window size and the cursor position in the correct
order, but was unusable at init time since scp->ts is not always
initialized then.  Adjust to use its internals.

I didn't notice any problems from the cursor reset.  The cursor should
be reset, and a previous fix was to reset it consistently a little
later.

Doing nothing for warm init works almost as well, if not better.  It
is not very useful to reset the escape state for mode changes, since
the reset is especially likely to be null then.  The escape state is
most likely to be non-initial and corrupted by its most normal uses
-- sloppy non-atomic output where a context switch or just mixing
stdout with stderr splits up escape sequences.
2017-04-12 16:21:55 +00:00
Bruce Evans
f3ac3a6e6f Special rendering methods for removing mouse cursors cannot be removed
like I hoped, since they are needed for removing parts over the border.
Continue fixing bugs in them.

In the vga planar mode renderer, remove removal of the part of the
image over the text window.  This was hard-coded for nearly 8x16 fonts
and in practice didn't remove enough for 8x8 fonts.  This used the
wrong attribute over cutmarked regions.  The caller refreshes with the
correct attribute later, so the attribute bug only caused flicker.
The caller uses the same hard-coding, so the refreshes fix up all the
spots with the wrong attribute, but keep missing the missed spots.
This still gives trails of bits of cursors for cursor motions in the
affected configurations (mainly depth 4 modes with 8x8) fonts.  8x14
fonts barely escape the problem since although the cursor is drawn
as 16x16, its active part is only 9x13 and the active part fits in
the hard-coded 2x2 character cell window for 8x14 fonts.  8x8 fonts
need a 2x3 window.

In the fb non-sparc64 renderer, the buggy image removal was buggier
and was already avoided by returning before it.  Remove it completely
and fix nearby style bugs.  It was essentially the same as for the vga
planar mode renderer (obfuscated by swapping x and y).  This was buggier
since fb should handle more types of hardware so the hard-coding is
wronger.

The remaining fb image removal is also buggier.  It never supported
software cursors drawn into the border, and the hardware cursor is
probably broken by other bugs to be fixed soon.
2017-04-10 06:19:09 +00:00
Bruce Evans
eeab8fcc4b Quick fix for removal of the mouse cursor in vga direct graphics modes
(that is, in all supported 8, 15, 16 and 24-color modes).  Moving the
mouse cursor while holding down a button (giving cut marking) left a
trail of garbage from misremoved mouse cursors (usually colored
rectangles and not cursor shapes).  Cases with a button not held down
worked better and may even have worked.

No renderer support for removing (software) mouse cursors is needed
(and many renderers don't have any), since sc_remove_mouse_image()
marks for update the region containing the image and usually much
more.  The mouse cursor can be (partially) over as many as 4 character
cells, and removing it in only the 1-4 cells occupied by it would be
best for efficiency and for avoiding flicker.  However,
sc_remove_mouse_image() can only mark a single linear region and
usually marks a full row of cells and 1 more to be sure to cover the
4 cells.  It always does this, so using the special rendering method
just wastes even more time and gives even more flicker.  The special
methods will be removed soon.

The general method always works.  vga_pxlmouse_direct() appeared to
defer to it by returning immediately if !on.  However,
vga_pxlmouse_direct() actually did foot-shooting using a disguised
saveunder method.  Normal order near a mouse move is:
  (1) remove the mouse cursor in the renderer (optional)
  (2) remove the mouse cursor again and refresh the screen over the
      mouse cursor and much more from the vtb.  When the mouse has
      actually moved and a button is down, many attributes in this
      region are changed to be up to date with the new cut marking
  (3) draw the keyboard cursor again if it was clobbered by the update
  (4) draw the mouse cursor image in its new position.
The bug was to remove the mouse cursor again in step (4), before the
drawing it again in (4), using a saveunder that was valid in step (1)
at best.  The quick fix is to use the saveunder in step (1) and not
in step (4).  Using it in step (4) also used it before it was
initialized, initially and after  mode and screen switches.
2017-04-08 10:00:39 +00:00
Bruce Evans
e53fbbe661 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.
2017-04-08 08:24:25 +00:00
Bruce Evans
912da69951 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.
2017-03-29 14:46:26 +00:00
Bruce Evans
d91400bf98 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.
2017-03-26 13:03:16 +00:00
Bruce Evans
4eb235fb4f Fix bright colors for syscons, and make them work for the first time
for vt.  Restore syscons' rendering of background (bg) brightness as
foreground (fg) blinking and vice versa, and add rendering of blinking
as background brightness to vt.

Bright/saturated is conflated with light/white in the implementation
and in this description.

Bright colors were broken in all cases, but appeared to work in the
only case shown by "vidcontrol show".  A boldness hack was applied
only in 1 layering-violation place (for some syscons sequences) where
it made some cases seem to work but was undone by clearing bold using
ANSI sequences, and more seriously was not undone when setting
ANSI/xterm dark colors so left them bright.  Move this hack to drivers.

The boldness hack is only for fg brightness.  Restore/add a similar hack
for bg brightness rendered as fg blinking and vice versa.  This works
even better for vt, since vt changes the default text mode to give the
more useful bg brightness instead of fg blinking.

The brightness bit in colors was unnecessarily removed by the boldness
hack.  In other cases, it was lost later by teken_256to8().  Use
teken_256to16() to not lose it.  teken_256to8() was intended to be
used for bg colors to allow finer or bg-specific control for the more
difficult reduction to 8; however, since 16 bg colors actually work
on VGA except in syscons text mode and the conversion isn't subtle
enough to significantly in that mode, teken_256to8() is not used now.

There are still bugs, especially in vidcontrol, if bright/blinking
background colors are set.

Restore XOR logic for bold/bright fg in syscons (don't change OR
logic for vt).  Remove broken ifdef on FG_UNDERLINE and its wrong
or missing bit and restore the correct hard-coded bit.  FG_UNDERLINE
is only for mono mode which is not really supported.

Restore XOR logic for blinking/bright bg in syscons (in vt, add
OR logic and render as bright bg).  Remove related broken ifdef
on BG_BLINKING and its missing bit and restore the correct
hard-coded bit.  The same bit means blinking or bright bg depending
on the mode, and we want to ignore the difference everywhere.

Simplify conversions of attributes in syscons.  Don't pretend to
support bold fonts.  Don't support unusual encodings of brightness.
It is as good as possible to map 16 VGA colors to 16 xterm-16
colors.  E.g., VGA brown -> xterm-16 Olive will be converted back
to VGA brown, so we don't need to convert to xterm-256 Brown.  Teken
cons25 compatibility code already does the same, and duplicates some
small tables.  This is mostly for the sc -> te direction.  The other
direction uses teken_256to16() which is too generic.
2017-03-18 11:13:54 +00:00
Bruce Evans
4ca582c4f2 The previous fix didn't ifdef out enough for sparc64 to actually work.
Fix this by using more dynamic initialization with simpler ifdefs for
the machine dependencies.  Find a frame buffer address in a more
portable way that at least compiles on sparc64.
2017-03-16 07:40:33 +00:00
Bruce Evans
b8188f52eb Fix the attribute for scteken_clear() (change it back from the user
user default normal attribute to the current attribute).

This change only fixes a logic error.  scterm_clear() used to be
used for terminal reset, but teken uses a general fill function for
that, leaving scterm_clear() only used for initialization and mode
change, when using the user default attribute is correct.  It is not
really a terminal function, but needs to sync its changes with the
terminal layer.  Syncing of the attribute is currently broken for
terminal reset, but works for initialization and mode change.
2017-03-11 13:56:06 +00:00
Bruce Evans
ad530aa98b 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.
2017-03-11 11:31:06 +00:00
Bruce Evans
eeb7d30e06 Rename scteken_revattr() to scteken_sc_to_te_attr(). scteken_revattr()
looked like it might handle reverse attributes, but it actually handles
conversion of attributes in the direction indicated by the new name.
Reverse attributes are just broken.

Rename scteken_attr() to scteken_te_to_sc_attr().  scteken_attr() looked
like it might give teken attributes, but it actually gives sc attributes.

Change scteken_te_to_sc_attr() to return int instead of unsigned int.
u_char would be enough, and it promotes to int, and syscons uses int
or u_short for its attributes everywhere else (u_short holds a shifted
form and it promotes to int too).
2017-03-10 14:25:38 +00:00
Bruce Evans
8f2cc27067 Start fixing some bugs in attribute handling.
This change just does cleanups missed in r56043 17 years ago.  The
default attributes were still stored in structs for the purpose of
changing them and passing around pointers to the defaults, but r56043
added another layer that made the defaults invariant and only used for
initialization and reset.  Just use the defaults directly.  This was
already done for the kernel defaults.  The defaults for reverse
attributes aren't actually used, but are ignored in layers that no
longer support them.
2017-03-10 11:44:09 +00:00
Bruce Evans
1b835e81ca Fix compilation on sparc64. The frame buffer address is in a field that
is unavailable on sparc64 only.  This makes the new ec_putc() a non-op
on sparc64 but still calls it.  On other non-x86 arches, it should
compile but might not work.

Reported by:	gjb
2017-03-10 10:25:48 +00:00
Bruce Evans
53f40ddc8e Implement ec_putc() (emergency kernel [syscons] console putc()) and use
it in emergency in sc_cnputc().

Locking fixes in sc_cnputc() previously turned off normal output in
near-deadlock conditions and added deferred output which might never
be completed.  Emergency output goes to the frame buffer using
sufficiently atomic non-blocking writes if the console is in text
mode (in graphics mode, nothing is done, modulo races setting the
graphics mode bit).  Screen updates overwrite the emergency output
if the emergency condition clears enough to reach them.

ec_putc() also works for "early" console output in normal x86 text
mode as soon as this mode is initialized (if ever).  This uses a
hard-coded x86 frame buffer address before cninit() and a hopefully
MI address after cninit().  But non-x86 is more likely to not support
text mode, when ec_putc() will be null.  ec_putc() has no dependencies
of syscons before cninit(), and only has them later to track syscons'
mode changes.  This commit doesn't attach ec_putc() for early use.

To test emergency use, put a breakpoint in central syscons output code
like sc_puts() and do some user output.  The system used to race or
deadlock in ddb output soon after entry to ddb.  The locking fixes
deferred the output until after leaving ddb, so ddb was unusable and
you had to try typing c[ontinue] blindly until it exited, or better use
a serial console in parallel.  Now the output goes to a window in the
middle 2/3 of the screen.  Scrolling is circular and there is no cursor,
but otherwise ec_putc() provides full dumb terminal functionality and
very fast output that hides artificates from dumb overwrites.
2017-03-04 08:47:31 +00:00
Bruce Evans
0a743c0957 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.
2017-03-04 06:19:12 +00:00
Yoshihiro Takahashi
2b375b4edd Remove pc98 support completely.
I thank all developers and contributors for pc98.

Relnotes:	yes
2017-01-28 02:22:15 +00:00
Oleksandr Tymoshenko
4af79d4f2b [evdev] Adds evdev support to sysmouse(4) driver
For horizontal (T-axis) wheel reporting which is not supported by
sysmouse protocol kern.evdev.sysmouse_t_axis sysctl is introduced.
It can take following values:

0 - no T-axis events (default)
1 - T-axis events are originated in ums(4) driver.
2 - T-axis events are originated in psm(4) driver.

Submitted by:	Vladimir Kondratiev <wulf@cicgroup.ru>
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D8597
2016-12-10 18:07:16 +00:00
Bruce Evans
90adad104b 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.
2016-09-01 19:18:26 +00:00
Bruce Evans
a95582c6fd 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.
2016-08-31 11:10:39 +00:00
Bruce Evans
81306e463e Start adding locking to sc_cngetc().
Restore an splx() lost in r228644.  We aren't nearly ready to remove
spl's.  They give hints about missing locking.  This lost one was
misplaced.  Dropping it early for convenience gave race windows for
accesses to the fkey buffer.  Giant locking accidentally fixed this
for non-console cases.

Put the spl's around the whole function.  Since there are many returns
that would need splx() just before them for a direct fix, split the
function into a wrapper that does the spl's and a "locked" function
that does the work.

Return earlier when no keyboard is attached to match the ordering in a
planned version.  This breaks the dubious feature of returning keys
from the fkey buffer after the keyboard has gone away.  Losing the keys
wouldn't matter, but we keep them too long now.
2016-08-30 10:57:19 +00:00
Bruce Evans
b430634b31 Add screen locking calls to sc cn grab and ungrab. The locking functions
just use the same mutex locking as sc cn putc so they have the same
defects.

The locking calls to acquire the lock are actually in sc cn open and close.
Ungrab has to unlock, although this opens a race window.

Change the direct mutex lock calls in sc cn putc to the new locking
functions via the open and close functions.  Putc also has to unlock, but
doesn't keep the screen open like grab.  Screen open and close reduce to
locking, except screen open for grab also attempts to switch the screen.

Keyboard locking is more difficult and still null, even when keyboard
input calls screen functions, except some of the functions have locks
too deep to work right.

This organization gives a single place to fix some of the locking.
2016-08-29 18:41:06 +00:00
Bruce Evans
d350ce61cf 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.
2016-08-25 13:46:52 +00:00
Bruce Evans
9f25943b82 Fix logic errors in bounds checks in previous commit. The 2-entry stack
was overrun for grab levels larger than 2.

Reported by:	pluknet
2016-08-25 12:04:57 +00:00
Bruce Evans
e866ca565f 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.
2016-08-24 18:59:24 +00:00
Bruce Evans
2078bf6ef0 Reorganise a little to prepare for locking fixes:
- in sccnopen(), open the keyboard before the screen.  The keyboard
  currently requires Giant (although it must be spinlocked to work
  correctly as a console), so the previous order would be a LOR if
  it has any semblance of locking.
- add a (currently dummy) state arg to scgetc().
2016-08-24 17:26:11 +00:00
Bruce Evans
79ef07d4c0 Clean up the new sc cn open and close functions (old sc cn grab and ungrab
functions).  Mainly, spell sc as itself instead of as scp->sc.
2016-08-15 20:17:48 +00:00
Bruce Evans
43e5b7b6b3 Restructure the grabbing functions into mere wrappers of new open and
close functions.  Scattered calls to sc_cnputc() and sc_cngetc() were
broken by turning the semi-reentrant inline context-switching code in
these functions into the grabbing functions.  cncheckc() calls for
panic dumps are the main broken case.  The grabbing functions have
special behaviour (mainly screen switching in sc_cngrab()) which makes
them unsuitable as replacements for the inline code.
2016-08-15 19:37:18 +00:00
Bruce Evans
430320729d 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.
2016-08-15 18:02:37 +00:00
Bruce Evans
1388e8b13e [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.
2016-08-15 17:11:05 +00:00
Bruce Evans
71e40e4a49 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 the latter usually left the
keyboard mode part of it 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.
2016-08-15 17:08:25 +00:00
Bruce Evans
304c3654d7 Disable some more unsafe things in (low level) console mode:
- never call up to the tty layer to restart output for keyboard input in
  console mode.  This was already disallowed in kdb mode.  Other cases
  are rarely reached.
- disable the reboot, halt and powerdown keys in console mode.  The suspend,
  standby and panic keys are still allowed, and aren't even conditonal
  on excessive configuration options.  Some of these actions are still
  available in ddb mode as ddb commands which are equally unsafe.  Some
  are useful at input prompts and should be restored when the locking is
  fixed.
- disallow bells in kdb mode (should be in console mode, but the flag for
  that is not available).  Visual bell gives very alarming behaviour by
  trying to use callouts which don't work in kdb mode.  Audio bell uses
  timeouts and hardware resources with mutexes that can deadlock in
  reasonable use of ddb.

Screen switches in kdb mode are not very safe, but they are important
functionality and there is a lot of code to make them sort of work.
2016-08-15 15:34:53 +00:00
Bruce Evans
abf3a584b6 Change all uses of 'debugger' to kdb_active and remove this variable. This
restores avoidance of doing dangerous things like calling wakeup() and
callouts while in ddb.

Initialization of 'debugger' was broken by removing the cndbctl() console
method that was used mainly in this driver to initialize 'debugger' and
switch to the console screen on entry to ddb.  The screen switch was
restored using the cngrab() method, but cngrab() is more general so it
should not initialize 'debugger' and never did.  'debugger' was just
an over-engineered alias for kdb_active anyway.  It existed because
kdb_active (when it was named ddb_active) was considered as a private
kdb variable, and there are ordering problems initializing the variables
atomically with the state that they represent, but an extra variable and
method to set it increased these problems.

The bug caused LORs, but WITNESS is normally misconfigured with
WITNESS_SKIPSIN so it doesn't check the spinlocks used by wakeup() and
callouts.
2016-08-15 14:28:16 +00:00
Bruce Evans
40de550ba7 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).
2016-08-15 12:56:45 +00:00
Pedro F. Giffuni
453130d9bf sys/dev: minor spelling fixes.
Most affect comments, very few have user-visible effects.
2016-05-03 03:41:25 +00:00
Pedro F. Giffuni
4ed3c0e713 sys: Make use of our rounddown() macro when sys/param.h is available.
No functional change.
2016-04-30 14:41:18 +00:00
Dag-Erling Smørgrav
23e6278ed9 Replace the cosine table with a sine table, which (due to the vagaries of
rounding) has better spread.  Implement fp16_sin() to go along with
fp16_cos().  In the rendering loop, switch from addition to subtraction
so the center of the pattern will be a trough rather than a peak.  This
is completely arbitrary, of course, but looks better to me.
2016-01-02 16:40:37 +00:00
Dag-Erling Smørgrav
a50b01d224 17 years and change after I wrote warp_saver, here's a simple plasma effect
(currently only three circular patterns) which requires quite a bit of
fixed-point arithmetic, including sqrt() and cos().  Happy New Year!
2016-01-01 04:04:40 +00:00
Mark Murray
d1b06863fb Huge cleanup of random(4) code.
* GENERAL
- Update copyright.
- Make kernel options for RANDOM_YARROW and RANDOM_DUMMY. Set
  neither to ON, which means we want Fortuna
- If there is no 'device random' in the kernel, there will be NO
  random(4) device in the kernel, and the KERN_ARND sysctl will
  return nothing. With RANDOM_DUMMY there will be a random(4) that
  always blocks.
- Repair kern.arandom (KERN_ARND sysctl). The old version went
  through arc4random(9) and was a bit weird.
- Adjust arc4random stirring a bit - the existing code looks a little
  suspect.
- Fix the nasty pre- and post-read overloading by providing explictit
  functions to do these tasks.
- Redo read_random(9) so as to duplicate random(4)'s read internals.
  This makes it a first-class citizen rather than a hack.
- Move stuff out of locked regions when it does not need to be
  there.
- Trim RANDOM_DEBUG printfs. Some are excess to requirement, some
  behind boot verbose.
- Use SYSINIT to sequence the startup.
- Fix init/deinit sysctl stuff.
- Make relevant sysctls also tunables.
- Add different harvesting "styles" to allow for different requirements
  (direct, queue, fast).
- Add harvesting of FFS atime events. This needs to be checked for
  weighing down the FS code.
- Add harvesting of slab allocator events. This needs to be checked for
  weighing down the allocator code.
- Fix the random(9) manpage.
- Loadable modules are not present for now. These will be re-engineered
  when the dust settles.
- Use macros for locks.
- Fix comments.

* src/share/man/...
- Update the man pages.

* src/etc/...
- The startup/shutdown work is done in D2924.

* src/UPDATING
- Add UPDATING announcement.

* src/sys/dev/random/build.sh
- Add copyright.
- Add libz for unit tests.

* src/sys/dev/random/dummy.c
- Remove; no longer needed. Functionality incorporated into randomdev.*.

* live_entropy_sources.c live_entropy_sources.h
- Remove; content moved.
- move content to randomdev.[ch] and optimise.

* src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h
- Remove; plugability is no longer used. Compile-time algorithm
  selection is the way to go.

* src/sys/dev/random/random_harvestq.c src/sys/dev/random/random_harvestq.h
- Add early (re)boot-time randomness caching.

* src/sys/dev/random/randomdev_soft.c src/sys/dev/random/randomdev_soft.h
- Remove; no longer needed.

* src/sys/dev/random/uint128.h
- Provide a fake uint128_t; if a real one ever arrived, we can use
  that instead. All that is needed here is N=0, N++, N==0, and some
  localised trickery is used to manufacture a 128-bit 0ULLL.

* src/sys/dev/random/unit_test.c src/sys/dev/random/unit_test.h
- Improve unit tests; previously the testing human needed clairvoyance;
  now the test will do a basic check of compressibility. Clairvoyant
  talent is still a good idea.
- This is still a long way off a proper unit test.

* src/sys/dev/random/fortuna.c src/sys/dev/random/fortuna.h
- Improve messy union to just uint128_t.
- Remove unneeded 'static struct fortuna_start_cache'.
- Tighten up up arithmetic.
- Provide a method to allow eternal junk to be introduced; harden
  it against blatant by compress/hashing.
- Assert that locks are held correctly.
- Fix the nasty pre- and post-read overloading by providing explictit
  functions to do these tasks.
- Turn into self-sufficient module (no longer requires randomdev_soft.[ch])

* src/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.h
- Improve messy union to just uint128_t.
- Remove unneeded 'staic struct start_cache'.
- Tighten up up arithmetic.
- Provide a method to allow eternal junk to be introduced; harden
  it against blatant by compress/hashing.
- Assert that locks are held correctly.
- Fix the nasty pre- and post-read overloading by providing explictit
  functions to do these tasks.
- Turn into self-sufficient module (no longer requires randomdev_soft.[ch])
- Fix some magic numbers elsewhere used as FAST and SLOW.

Differential Revision: https://reviews.freebsd.org/D2025
Reviewed by: vsevolod,delphij,rwatson,trasz,jmg
Approved by: so (delphij)
2015-06-30 17:00:45 +00:00
Andriy Gapon
85f95fffd7 hook userland threads suspend + resume into acpi suspend code
Also, split power_suspend into power_suspend and power_suspend_early.

power_suspend_early is called before the userland is frozen.
power_suspend is called after the userland is frozen.

Currently only VT switching is hooked to power_suspend_early.
This is needed because switching away from X server requires its
cooperation, so obviously X server must not be frozen when that happens.

Freezing userland during ACPI suspend is useful because not all drivers
correctly handle suspension concurrent with other activity.  This is
especially applicable to drivers ported from other operating systems
that suspend all software activity between placing drivers and hardware
into suspended state.
In particular drm2/radeon (radeonkms) depends on the described
procedure.  The driver does not have any internal synchronization
between suspension activities and processing of userland requests.

Many thanks to kib for the code that allows to freeze and thaw all
userland threads.

Note that ideally we also need to park / inhibit (non-special) kernel
threads as well to ensure that they do not call into drivers.

MFC after:	17 days
2015-01-27 17:33:18 +00:00
Xin LI
a1ff3f20f9 Fix sos@'s name.
MFC after:	2 weeks
2015-01-07 21:44:57 +00:00
Hans Petter Selasky
af3b2549c4 Pull in r267961 and r267973 again. Fix for issues reported will follow. 2014-06-28 03:56:17 +00:00
Glen Barber
37a107a407 Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output,
such as:

 1) no output from sysctl(8)
 2) erroneously returning ENOMEM with tools like truss(1)
    or uname(1)
 truss: can not get etype: Cannot allocate memory
2014-06-27 22:05:21 +00:00
Ed Maste
59644098f8 Use a common tunable to choose between vt(4)/sc(4)
With this change and previous work from ray@ it will be possible to put
both in GENERIC, and have one enabled by default, but allow the other to
be selected via the loader.

(The previous implementation had separate kern.vt.disable and
hw.syscons.disable tunables, and would panic if both drivers were
compiled in and neither was explicitly disabled.)

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
2014-06-27 17:50:33 +00:00
Hans Petter Selasky
3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after:	2 weeks
Sponsored by:	Mellanox Technologies
2014-06-27 16:33:43 +00:00
Aleksandr Rybalko
3fc3ca2652 Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.
Sponsored by:	The FreeBSD Foundation
2014-06-18 22:23:10 +00:00
Julio Merino
50b9fb4657 Fix comment introduced in r262480: it's 1920x1200, not 1980x1200.
PR:		kern/180558
MFC after:	5 days
2014-02-25 23:04:39 +00:00
Julio Merino
478b27042c 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
2014-02-25 13:48:05 +00:00
Ed Schouten
a6c26592f1 Extend libteken to support CJK fullwidth characters.
Introduce a new formatting bit (TF_CJK_RIGHT) that is set when putting a
cell that is the right part of a CJK fullwidth character. This will
allow drivers like vt(9) to support fullwidth characters properly.

emaste@ has a patch to extend vt(9)'s font handling to increase the
number of Unicode -> glyph maps from 2 ({normal,bold)} to 4
({normal,bold} x {left,right}). This will need to use this formatting
bit to determine whether to draw the left or right glyph.

Reviewed by:	emaste
2013-12-20 21:31:50 +00:00
Mark Murray
f02e47dc1e Snapshot. This passes the build test, but has not yet been finished or debugged.
Contains:

* Refactor the hardware RNG CPU instruction sources to feed into
the software mixer. This is unfinished. The actual harvesting needs
to be sorted out. Modified by me (see below).

* Remove 'frac' parameter from random_harvest(). This was never
used and adds extra code for no good reason.

* Remove device write entropy harvesting. This provided a weak
attack vector, was not very good at bootstrapping the device. To
follow will be a replacement explicit reseed knob.

* Separate out all the RANDOM_PURE sources into separate harvest
entities. This adds some secuity in the case where more than one
is present.

* Review all the code and fix anything obviously messy or inconsistent.
Address som review concerns while I'm here, like rename the pseudo-rng
to 'dummy'.

Submitted by:	Arthur Mesh <arthurmesh@gmail.com> (the first item)
2013-10-04 06:55:06 +00:00
Jung-uk Kim
ba53f0d5ca Reload font when syscons(4) is resuming without switching mode.
Reported by:	adrian (more than a year ago)
Prodded by:	adrian (less than a month ago)
2013-07-17 23:29:56 +00:00
Konstantin Belousov
1dc72d3681 On some generations of the Intel GPU, disabling of the VGA Display
stops updating the vertical retrace indicator.  The text mouse
renderer in syscons is executing from the callout and spins waiting
for the start of next frame.  As result, after the X server finishes,
since the VGA cannot be turned on, but syscons does not know about
this, the clock swi spins forever.

Hack around the problem by disabling wait for the retrace if KMS is
activated.

Diagnosed and tested by:	Michiel Boland <boland37@xs4all.nl>
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
2013-06-18 20:19:09 +00:00
Davide Italiano
6b98f11545 MFcalloutng (r244249, r244306 by mav):
- Switch syscons from timeout() to callout_reset_flags() and specify that
precision is not important there -- anything from 20 to 30Hz will be fine.
- Reduce syscons "refresh" rate to 1-2Hz when console is in graphics mode
and there is nothing to do except some polling for keyboard.  Text mode
refresh would also be nice to have adaptive, but this change at least
should help laptop users who running X.

Sponsored by:	Google Summer of Code 2012, iXsystems inc.
Tested by:	flo, marius, ian, markj, Fabian Keil
2013-03-04 14:00:58 +00:00
Hans Petter Selasky
68fdacf7c5 Make sure that all mouse buttons are released when clients
using /dev/consolectl close. This fixes a problem where if
a USB mouse is detached while a button is pressed, that
button is never released.

MFC after:	1 week
2013-02-06 11:16:18 +00:00
Ed Schouten
305921c48e Add tty_set_winsize().
This removes some of the signalling magic from the Syscons driver and
puts it in the TTY layer, where it belongs.
2012-11-03 22:21:37 +00:00
Oleksandr Tymoshenko
e1f04cd024 Piggyback MIPS changes and add ARM syscons support for devices with
framebuffer

While here - sort #if defined() order alphabetically
2012-08-25 23:59:31 +00:00
Robert Watson
8122a592ee Provide basic glue to allow syscons to be used on MIPS, modelled
on PowerPC support.  This was clearly not something syscons was
designed to do (very specific assumptions about the nature of VGA
consoles on PCs), but fortunately others have long since blazed
the way on making it work regardless of that.

Sponsored by:	DARPA, AFRL
2012-08-25 08:09:37 +00:00
Hans Petter Selasky
d1eacc02f1 Move tty_opened_ns() into syscons.c which is currently the
only client of this macro.

Suggested by:	ed @
MFC after:	1 week
2012-03-29 15:47:29 +00:00
Hans Petter Selasky
8dbeb1b6cc Fix for NULL-pointer panic during boot, if keys are pressed too early.
MFC after:	1 week
2012-03-29 14:53:14 +00:00
Ulrich Spörlein
9a14aa017b Convert files to UTF-8 2012-01-15 13:23:18 +00:00
Andriy Gapon
b133becced sc_cngrab: switch to console vty when possible
In the future we may want to perform the switch even if the console is
currently in the graphics mode by trying to reset the video adapter first
(e.g. by executing vesa/vga bios post).  That would probably require
some sort of a one-way flag as returning the control of the console back
to the interrupted application most likely would result in a mess.

Reviewed by:	emaste
MFC after:	2 months
2011-12-21 12:21:22 +00:00
Andriy Gapon
8f3ae92165 syscons: provide a first iteration of cngrab/cnungrab implementation
- put underlying keyboard(s) into the polling mode for the whole
  duration of the grab, instead of the previous behavior of going into
  and out of the polling mode around each polling attempt
- ditto for setting K_XLATE mode and enabling a disabled keyboard

Inspired by:	bde
MFC after:	2 months
2011-12-17 15:57:39 +00:00
Andriy Gapon
9976156f12 kern cons: introduce infrastructure for console grabbing by kernel
At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input.  In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by:	bde
MFC after:	2 months
2011-12-17 15:08:43 +00:00
Andriy Gapon
8538a18594 syscons: make sc_puts static as it is used only privately
Perhaps sc_puts should also be renamed to scputs to follow the implied
naming conventions in the file...

MFC after:	2 weeks
2011-12-11 21:10:11 +00:00
Ed Schouten
6472ac3d8a Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
2011-11-07 15:43:11 +00:00
Robert Millan
a2c22d416d Add a few improvements to utf-8 -> cp436 console map
(mostly with Catalan characters in mind, but it probably
benefits other languages).

The new mappings are as follows:

▮ -> █
ÀÈÍÏÓÒÚ -> AEIIOOU
ŀ / Ŀ -> l / L

Reviewed by:	ed
Approved by:	kib (mentor)
2011-10-28 20:00:30 +00:00
Kip Macy
8451d0dd78 In order to maximize the re-usability of kernel code in user space this
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.

Reviewed by:	rwatson
Approved by:	re (bz)
2011-09-16 13:58:51 +00:00
Robert Watson
a608af7817 Add support for alternative break-to-debugger to syscons(4). While most
keyboards allow console break sequences (such as ctrl-alt-esc) to be
entered, alternative break can prove useful under virtualisation and
remote console systems where entering control sequences can be
difficult or unreliable.

MFC after:	3 weeks
Approved by:	re (bz)
2011-08-27 22:10:45 +00:00
Robert Watson
4cf7545589 Attempt to make break-to-debugger and alternative break-to-debugger more
accessible:

(1) Always compile in support for breaking into the debugger if options
    KDB is present in the kernel.

(2) Disable both by default, but allow them to be enabled via tunables
    and sysctls debug.kdb.break_to_debugger and
    debug.kdb.alt_break_to_debugger.

(3) options BREAK_TO_DEBUGGER and options ALT_BREAK_TO_DEBUGGER continue
    to behave as before -- only now instead of compiling in
    break-to-debugger support, they change the default values of the
    above sysctls to enable those features by default.  Current kernel
    configurations should, therefore, continue to behave as expected.

(4) Migrate alternative break-to-debugger state machine logic out of
    individual device drivers into centralised KDB code.  This has a
    number of upsides, but also one downside: it's now tricky to release
    sio spin locks when entering the debugger, so we don't.  However,
    similar logic does not exist in other device drivers, including uart.

(5) dcons requires some special handling; unlike other console types, it
    allows overriding KDB's own debugger selection, so we need a new
    interface to KDB to allow that to work.

GENERIC kernels in -CURRENT will now support break-to-debugger as long as
appropriate boot/run-time options are set, which should improve the
debuggability of BETA kernels significantly.

MFC after:	3 weeks
Reviewed by:	kib, nwhitehorn
Approved by:	re (bz)
2011-08-26 21:46:36 +00:00
Ed Schouten
78d4d8eeb2 Restore binary compatibility for GIO_KEYMAP and PIO_KEYMAP.
Back in 2009 I changed the ABI of the GIO_KEYMAP and PIO_KEYMAP ioctls
to support wide characters. I created a patch to add ABI compatibility
for the old calls, but I didn't get any feedback to that.

It seems now people are upgrading from 8 to 9 they experience this
issue, so add it anyway.
2011-07-17 08:19:19 +00:00
Ed Schouten
7c9669276e Fix whitespace inconsistencies in the TTY layer and its drivers owned by me. 2011-06-26 18:26:20 +00:00
Jung-uk Kim
b10c3d1c15 Move VT switching hack for suspend/resume from bus drivers to syscons.c
using event handlers.  A different version was

Submitted by:	Taku YAMAMOTO (taku at tackymt dot homeip dot net)
2011-05-09 18:46:49 +00:00
Jung-uk Kim
1658038ce7 Rename a variable to match scvidctl.c. 2010-11-30 17:34:15 +00:00
Jung-uk Kim
732e8e1632 Stop hardcoding default font size. 2010-11-30 17:32:28 +00:00
Jung-uk Kim
fd7a9ebcca Clean up code a bit to make it more readable. 2010-11-30 16:46:15 +00:00
Jung-uk Kim
82515b4f1f Clean up code a bit to make it more readable. 2010-11-29 22:20:44 +00:00
Jung-uk Kim
0cb06f72d5 Honor font size for the video mode when default fonts are compiled in kernel
and VESA mode is enabled from loader.
2010-11-29 22:19:19 +00:00
Rebecca Cran
b1ce21c6ef Fix typos.
PR:	bin/148894
Submitted by:	olgeni
2010-11-09 10:59:09 +00:00
Rui Paulo
cd1fa5bd4d Explicitly tell the compiler that we don't care about the return value
of kbdd_ioctl().
2010-10-13 11:37:12 +00:00
Jung-uk Kim
a90b8833d2 Rework r210248. Although it fixed most of problems, it did not fix one
particular edge case where X-axis resolution is not multiple of font width.
Now we just advance enough scan lines, then deduct a partial scan line.
It is more intuitive than the previous code.  Apply the same wisdom to EGA
and VGA planar renderers for consistency.

Reported by:	David DEMELIER (demelier dot david at gmail dot com)
2010-09-17 23:09:31 +00:00
Jung-uk Kim
25a14f561c Improve style slightly. 2010-07-19 20:31:04 +00:00
Jung-uk Kim
490770af47 Fix two long-standing line wrapping bugs in VGA renderer for pixel mode.
Font size may be smaller than 16 and logical scan line may be larger than
the displayed scan line.

MFC after:	3 days
2010-07-19 18:56:18 +00:00
Jung-uk Kim
dd962f5b8a Suspend screen updates when the video controller is powered down. 2010-05-22 07:35:17 +00:00
Jung-uk Kim
3504769505 Correct beastie_saver module name. 2010-04-07 18:42:21 +00:00
Jung-uk Kim
3cab2f6db9 Add the official FreeBSD logo image file for logo_saver. 2010-04-07 17:07:06 +00:00
Jung-uk Kim
f989dcca3e Copy Beastie image file to prepare for an official logo image. 2010-04-07 17:03:05 +00:00
Jung-uk Kim
4cc5f38e97 Refine r204265. We want the standard VGA palette for packed pixel mode. 2010-03-29 22:41:30 +00:00
Jung-uk Kim
c2bce7cc39 Align memory access of 24-bit pixel renderer to word boundary. 2010-03-24 15:40:18 +00:00
Jung-uk Kim
4d52abfb0c Separate 24-bit pixel draw from 32-bit case. Although it is slower, we do
not want to write a useless zero to inaccessible memory region.
2010-03-23 22:16:57 +00:00
Jung-uk Kim
4a9b63a454 Improve VESA mode switching via loader tunable `hint.sc.0.vesa_mode'.
The most notable change is history buffer is fully saved/restored now.
2010-02-24 20:13:34 +00:00
Jung-uk Kim
8d521790d0 Yet another attempt to make palette loading more safer:
- Add a separate palette data for 8-bit DAC mode when SC_PIXEL_MODE is set
and fill it up with default gray-scale palette data for text.  Now we don't
have to set `hint.sc.0.vesa_mode' to get the default palette data.
- Add a new adapter flag, V_ADP_DAC8 to track whether the controller is
using 8-bit palette format and load correct palette when switching modes.
- Set 8-bit DAC mode only for non-VGA compatible graphics mode.
2010-02-23 21:51:14 +00:00
Ivan Voras
b8bba24e06 The New and Improved snake_server - Service Pack 1: now even more
sensitive to load average variations!
2010-02-23 15:27:07 +00:00
Ivan Voras
c0414ca779 Upgrade the "snake" syscons screensaver to the new, multimedia version!
Now, with color! And system load averages!

Amused by it:	gnn
2010-02-23 15:12:41 +00:00
Robert Noland
cfd7bacef2 Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.
This replaces d_mmap() with the d_mmap2() implementation and also
changes the type of offset to vm_ooffset_t.

Purge d_mmap2().

All driver modules will need to be rebuilt since D_VERSION is also
bumped.

Reviewed by:	jhb@
MFC after:	Not in this lifetime...
2009-12-29 21:51:28 +00:00
Ed Schouten
5b19140604 Include <sys/ttydefaults.h>, instead of doing it through <sys/termios.h>.
I want to prevent the header polution of <sys/termios.h> eventually.
2009-11-28 16:25:55 +00:00
Konstantin Belousov
07ff915720 Fix pgsignal() call after signature change in r199355.
Reported and tested by:	bf1783 googlemail com
MFC after:	1 month
2009-11-17 19:24:26 +00:00
Ed Schouten
4b2361f811 Convert syscons on i386 to TERM=xterm.
TEKEN_XTERM is now gone. Because we always use xterm mode now, we only
need a TEKEN_CONS25 switch to go back to cons25.
2009-11-13 11:28:54 +00:00
Ed Schouten
e42fc36867 Switch the default terminal emulation style to xterm for most platforms.
Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:

- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
  regions.
- A very hard transition path to support for modern character sets like
  UTF-8.

Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.

I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.

IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):

- Run the application inside script(1), try to reduce the problem and
  send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
  TERM=cons25' so you can run applications the same way you did before.
  You can also build your kernel with `options TEKEN_CONS25' to make all
  virtual terminals use the cons25 emulator by default.

Discussed on:	current@
2009-11-13 05:54:55 +00:00