complications in the previous methods.
r346761 broke showing the mouse cursor after changing its state from
off to on (including initially), since showing the cursor uses the
state to decide whether to actually show and the state variable was
not changed until after null showing. Moving the mouse or copying
under the cursor fixed the problem. Fix this and similar problems for
the on to off transition by changing the state variable before drawing
the cursor.
r346641 failed to turn off the mouse cursor on exit from vgl. It hid
the cursor only temporarily for clearing. This doesn't change the state
variable, so unhiding the cursor after clearing restored the cursor if its
state was on. Fix this by changing its state to VGL_MOUSEHIDE using the
application API for changing the state.
Remove the VGLMouseVisible state variable and the extra states given by it.
This was an optimization that was just an obfuscation in at least the
previous version.
Staticize VGLMouseAction(). Remove VGLMousePointerShow/Hide() except as
internals in __VGLMouseMode(). __VGLMouseMouseMode() is the same as the
application API VGLMouseMouseMode() except it returns the previous mode
which callers need to know to restore it after hiding the cursor.
Use the refactoring to make minor improvements in a simpler way than was
possible:
- in VGLMouseAction(), only hide and and unhide the mouse cursor if the
mouse moved
- in VGLClear(), only hide and and unhide the mouse cursor if the clearing
method would otherwise clear the cursor.
support for 24-bit modes.
The non-segmented case has worked for a long time, but the segmented
case could never have worked since 24-bit accesses may cross a window
boundary but the window was not changed in the middle of the specialized
24-bit accesses for writing a single pixel.
VGLSetVScreenSize(), but is not restored by mode switches to at least
standard text mode, so must be restored explicitly. Standard text mode
displayed blanks when the line width was doubled.
in r346631. VGLEnd() clears some state variables as it restores state,
but not all of them, so it still needs to clear a single state variable
to indicate that it has completed. Put this clearing back where it was
(at the start instead of the end) to avoid moving bugs in the signal
handling.
The mouse signal SIGUSR2 was not turned off for normal termination and
in some other cases. Thus mouse signals arriving after the frame
buffer was unmapped always caused fatal traps. The fatal traps occurred
about 1 time in 5 if the mouse was wiggled while vgl is ending.
The screen switch signal SIGUSR1 was turned off after clearing the
flag that it sets. Unlike the mouse signal, this signal is handled
synchronously, but VGLEnd() does screen clearing which does the
synchronous handling. This race is harder to lose. I think it can
get vgl into deadlocked state (waiting in the screen switch handler
with SIGUSR1 to leave that state already turned off).
Turn off the mouse cursor before clearing the screen in VGLEnd().
Otherwise, clearing is careful to not clear the mouse cursor. Undrawing
an active mouse cursor uses a lot of state, so is dangerous for abnormal
termination, but so is clearing. Clearing is slow and is usually not
needed, since the kernel also does it (not quite right).
code for reading from the frame buffer.
Reading from the frame buffer is usually much slower than writing to
the frame buffer. Typically 10 to 100 times slower. It old modes,
it takes many more PIOs, and in newer modes with no PIOs writes are
often write-combined while reads remain uncached.
Reading from the frame buffer is not very common, so this change doesn't
give speedups of 10 to 100 times. My main test case is a floodfill()
function that reads about as many pixels as it writes. The speedups
are typically a factor of 2 to 4.
Duplicating writes to the shadow buffer is slower when no reads from the
frame buffer are done, but reads are often done for the pixels under the
mouse cursor, and doing these reads from the shadow buffer more than
compensates for the overhead of writing the shadow buffer in at least the
slower modes. Management of the mouse cursor also becomes simpler.
The shadow buffer doesn't take any extra memory, except twice as much
in old 4-plane modes. A buffer for holding a copy of the frame buffer
was allocated up front for use in the screen switching signal handler.
This wasn't changed when the handler was made async-signal safe. Use
the same buffer the shadow (but make it twice as large in the 4-plane
modes), and remove large special code for writing it as well as large
special code for reading ut. It used to have a rawer format in the
4-plane modes. Now it has a bitmap format which takes twice as much
memory but can be written almost as fast without special code.
VIDBUFs that are not the whole frame buffer were never supported, and the
change depends on this. Check for invalid VIDBUFs in some places and do
nothing. The removed code did something not so good.
not doing any unnecessary PIO instructions or refusing to start when the
i/o privilege needed for these instructions cannot be acquired.
This turns off useless palette management in direct modes. Palette
management had no useful effect since the hardware palette is not used
in these modes.
This transiently acquires i/o privilege if possible as needed to give
VGLSetBorder() and VGLBlankDisplay() a chance of working. Neither has
much chance of working. I was going to drop support for them in direct
modes, but found that VGLBlankDisplay() still works with an old graphics
card on a not so old LCD monitor.
This has some good side effects: reduce glitches for managing the palette
for screen switches, and speed up and reduce async-signal-unsafeness in
mouse cursor drawing.
with old kernels, by breaking the support for large frame buffers in the
same way as for current kernels.
Large frame buffers may be too large to map into kva, and the kernel
(syscons) only uses the first screen page anyway, so r203535, r205557
and 248799 limit the buffer size in VESA modes to the first screen
page, apparently without noticing that this breaks applications by
using the same limit for user mappings as for kernel mappings. In
vgl, this makes the virtual screen the same as the physical screen.
However, this is almost a feature since clearing and switching large
(usually mostly unused) frame buffers takes too long. E.g., on a 16
year old low-end AGP card it takes about 12 seconds to clear the 128MB
frame buffer in old kernels that map it all and also map it with slow
attributes (e.g., uncacheable). Older PCI cards are even slower, but
usually have less memory. Newer PCIe cards are faster, but may have
many GB of memory. Also, vgl malloc()s a shadow buffer with the same
size as the frame buffer, so large frame buffers are even more wasteful
in applications than in the kernel.
Use the same limit in vgl as in newer kernels.
Virtual screens and panning still work in non-VESA modes that have
more than 1 page. The reduced buffer size in the kernel also breaks
mmap() of the last physical page in modes where the reduced size is
not a multiple of the physical page size. The same reduction in vgl
only reduces the virtual screen size.
Correct restoring was only attempted for mode 258 (800x600x4 P). (This
was the only useful graphics mode supported in the kernel until 10-15
years ago, and is still the only one explicitly documented in the man
page). The comment says that it is the geometry (subscreen size) that
is restored, but it seems to only be necessary to restore the font
size, with the geometry only needed since it is set by the same ioctl.
The font size was not restored for this mode, but was forced to 16.
For other graphics modes, the font size was clobbered to 0. This
confuses but doesn't crash the kernel (font size 0 gives null text).
This confuses and crashes vidcontrol. The only way to recover was to
use vidcontrol to set the mode to any text mode on the way back to the
original graphics mode.
vidcontrol gets this wrong in the opposite way when backing out of
changes after an error. It restores the font size correctly, but
forces the geometry to the full screen size.
r80270 has the usual wrong fix for unsafe signal handling -- just set
a flag and return to let an event loop check the flag and do safe
handling. This never works for signals like SIGBUS and SIGSEGV that
repeat and works poorly for others unless the application has an event
loop designed to support this.
For these signals, clean up unsafely as before, except for arranging that
nested signals are fatal and forcing a nested signal if the cleanup doesn't
cause one.
Support for 16-bit and 32-bit Truecolor modes was supposed to be
complete in r70991 of main.c and in nearby revisions for other files, but
it was broken by the overruns in most cases (all cases were the mouse
is enabled, and most cases where bitmaps are used). r70991 also
uninintentionally added support for depths 9-15, 17-23 and 25-31.
Depth 24 was more obviously broken and its support is ifdefed out. In
the other ranges, only depth 15 is common. It was broken by buffer
overruns in all cases.
bitmap.c:
- the static buffer was used even when it was too small (but it was
large enough to often work accidentally in depth 16)
- the size of the dynamically allocated buffer was too small
- the sizing info bitmap->PixelBytes was not inititialzed in the bitmap
constructor. It often ended up as 0 for MEMBUFs, so using it in more
places gave more null pointer accesses. (It is per-bitmap, but since
conversion between bitmaps of different depths is not supported (except
from 4 bits by padding to 8), it would work better if it were global.)
main.c:
- depths were rounded down instead of up to a multiple of 8, so PixelBytes
was 1 too small for depths above 8 except 16, 24 and 32.
- PixelBytes was not initialized for 4-bit planar modes. It isn't really
used for frame buffer accesses in these modes, but needs to be 1 in
MEMBUF images.
mouse.c:
- the mouse cursor buffers were too small.
vgl.h:
- PixelBytes was not initialized in the static bitmap constructor. It
should be initialized to the value for the current mode, but that is
impossible in a static constructor. Initialize it to -1 so as to
fail if it is used without further initialization.
All modes that are supposed to be supported now don't crash in
nontrivial tests, and almost work. Missing uses of PixelBytes now
give in-bounds wrong pointers instead of overruns. Misconversions of
bitmaps give multiple miscolored mouse cursors instead of 1 white one,
and similarly for bitmaps copied through a MEMBUF.
args (neither MAP_PRIVATE nor MAP_SHARED). It was broken in r271635
and/or r271724 by stricter checking. The compatibility code in r271724
doesn't work for my old binaries (actually new binaries with old
libraries).
PR: needed to test the fix for PR 162373
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified 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.
immediately when a signal is caught. Instead, defer
program termination until the next call to VGLCheckSwitch().
Otherwise, the video card may not be restored correctly
if the signal is seen while inside libvgl functions.
MFC after: 1 week
supported since it's not easy to put 3 bytes accross 64Kb windows
of memory. This should not be such a problem with linear framebuffers.
There is no major interface modification except that the color type
becomes u_long instead of byte. So one just need to recompile his
application.
Approved by: Soren Schmidt <sos@freebsd.dk>
Replace all in-tree uses with necessary subset of <sys/{fb,kb,cons}io.h>.
This is also the appropriate fix for exo-tree sources.
Put warnings in <machine/console.h> to discourage use.
November 15th 2000 the warnings will be converted to errors.
January 15th 2001 the <machine/console.h> files will be removed.
It adds new functions and extend some structures and can handle
VESA modes.
- Update the man page.
- Bump the library version number.
(The old version will be added to compat3x.)
- Slightly rearrange VGLCheckSwitch() to ensure the display content
will be correctly restored when switching back to the vty where
the vgl program is running.
- VGLEnd() should clear the screen only when the vty is in the
foreground.
Discussed with: sos
keyboard.c
- Call tcsetattr() in VGLKeyboardEnd() to restore tty, only when
tty attributes have been previously saved.
PR: misc/9524
Submitted by: Katusyuki 'kei' Maeda (kei@nanet.co.jp)
- Set up the tty raw mode correctly.
main.c
- Restore VESA_800x600 raster text mode correctly in VGLEnd().
Submitted by: des
text.c
- Allocate the correct size of a font buffer in VGLSetFontFile().
I forgot the submitter ;-(
simple.c, bitmap.c
- Fix address calculation for the VGA mode X in VGLGetXY() and
VGLBitmapCopy().
- Fix typo (dsty -> dstx) in __VGLBitmapCopy().
Reviewed by: sos
