RISC OS and look for a matching mode in a list of standard
video modes. This removes the requirement for compiling
RISC OS monitor definitions into the kernel. [bjh21 20060820]
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.
While it can be made to compile, the paradigm is not quite right because
it attempts to contact the filesystem during autoconfig which sometimes
causes a panic. Even if that was fixed, there is another potential problem
in that the driver tries/sleeps/tries/sleeps and the sleep could
theoretically sleep past the rc.d/btconfig stage and the controller
would remain unconfigured.
So, I have prepared a different method for loading the firmware to
Broadcom BCM2033 chip based devices. A package 'sysutils/bcmfw' will load
the firmware files via a ugen(4) device interface.
This update removes the ubtbcmfw(4) driver and adds a table to the ubt(4)
driver so that it will not attach to Broadcom BCM2033 based devices before
the firmware was loaded.
This fixes kern/34219
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.
fixes and caveats:
- will switch to 32bit colour, 8bit support needs some more work
- added support for fonts with widths that aren't multiples of 8
- for now the driver will always try to become system console
- mode switching works but is ugly
- all the acceleration bits work
- X should work with wsfb, mmap() needs some more work
- it still needs a hack to allow wsdisplay_cnattach to be called twice
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.
