using a completely bogus heuristic to guess at one. This might cause FIFO
underruns in particularly exciting video modes, but it also makes more
boring ones work correctly.
the nearest one, rather than the first one with the same resolution. This
is likely to be useful when the bootloader finally passes a valid frame rate.
For now, it just favours flickery over non-functional.
we use the standard mode list from videomode.c rather than one generated
by makemodes.awk. This is less useful than it might be since without a useful
frame rate from the bootloader we're likely to end up choosing a screen mode
that's either flickery or too fast for the monitor (or DRAM bandwidth).
used for anything. Rearrange things so that it doesn't any more, and
just produces an array of struct videomode. modedefs.c is looking
suspiciously much like videomode.c now.
the kernel, removing an element from struct vidc_mode. The calculation
is a bit pointless at the moment anyway, since both bootloaders pass in
a constant 56, but that might get fixed one day.
struct videomode doesn't have a way to record border widths (though I
wonder if VESA's "margins" are the same thing), so we now just treat them
as zero. Tested on my NC, which still seems to be working.
to RiscBSD and had been lurking in dark corners scaring people (mostly me)
for far too long. It will be missed, but not much, and I hope we can clear
up any fallout before 5.0.
While I'm in the area, also remove rpckbd(4), since pckbd(4) has
been supported on acorn32 for ages.
requested by uwe@. These were wrong because they were receiving an
emulcookie yet they were accessops (thus having to receive an accesscookie).
Instead, just handle the WSDISPLAYIO_{GET,PUT}WSCHAR ioctls from the
driver's ioctl accessop.
As this reduces the amount of code needed to handle these operations to
two small functions in each driver, remove the WSDISPLAY_CHARFUNCS kernel
option.
Reviewed by, at least, uwe@ and macallan@. No objections in tech-kern@.
to the screen on which they are being called. The driver cannot guess
this by itself but it is needed to implement, at least, the getwschar and
putwschar functions in the correct place. There are no functional changes
yet.
Tested on i386 (vga, vga_raster, machfb, vesafb), macppc and sparc64.
Suggested and reviewed by macallan@.
-Wcast-qual differently, by instead changing the signatore of those
"functions" to take a "volatile struct timeval*" instead of a
"struct timeval*". Many places, these functions are called with
&time, and time is declared as volatile in <sys/kernel.h>. This
way we can get rid of all the ugly casts which now also triggered
warnings, and caused more code to be added to work around the
problem.
Reviewed by thorpej.
