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.
Add a few more kernel configurations to synopsis.
Mention wscons and wsdisplay.
Describe the kernel options.
Add SEE ALSO section.
Mention about VESAFB_PM hanging systems.
Review by jmcneill on tech-kern list.
Most of the testing was done on MIPS hardware -- it probably needs work before
it will be useful with x86 hardware, and it is probably incompatible with
the X11 server.
"ATI Technologies Inc. ("ATI") has not assisted in the creation of, and
does not endorse, this software. ATI will not be responsible or liable
for any actual or alleged damage or loss caused by or in connection with
the use of or reliance on this software."
Enjoy!
