> Aye, but if you know enough to change resolutions, you probably also
> know enough to accurately determine the amount of video ram that you've
> got.  I don't want to think about the IIci/si/etc that might rearrange
> how much memory that they're using when they change video modes (since
> they use DRAM and NetBSD uses the unused space at boot-time).  There are
> a couple of options here, but no relatively simple and ideal one that I
> can think of.

The true sizing of VRAM is actually one of the things I may add in later
intvid releases. While a particular Quadra might be capable of certain
resolutions in hardware they may not have the VRAM to back it up. The driver
must know the size of the VRAM so it can calculate a list of legal
combinations of resolutions and bitdepths at config time.

There is a great deal of autosizing that must be done including the size
of the ROMs which is necessary to detect what type of internal video is
on the machine (i.e. have a look at the ROM's sResources). We could cheat
on this one by having the booter pass in the size but I'd rather rely less
on booter variables as someday this may be less of an option if somebody
makes a "lilo" style boot loader.

I think I finally understand what you guys meant by memory wrapping occuring
in RAM when the "write at 2 megs see if 1 meg changes" idea was presented.
I think I've got a little snippet of code in mind for autodetection.

Your point about the IIci/IIsi is well taken but I believe this can be
special-cased since these are the only two machines without separate VRAM.
If you're big into RAM conservation you can boot solid into one mode. If
you've got plenty of RAM the booter can boot into the highest mode so
NetBSD doesn't suck up all the RAM needed by the video controller. Or this
could even be accomplished in the kernel early on in the memory mapping phase.

Either way, right now I can see about 4 tons of assumptions that are being
made in how the kernel figures out things like frame buffer size that just
aren't valid in cases where you can swap resolutions. Even worse, there
are cases such how to calculate rowbytes for internal video if it is not
the console at boot time. Right now, the kernel simply assumes that the
internal video is the console and grf_iv grabs it's width from the
rowbytes passed in by the booter. What happens if this is not the case?

I have alot of work to do... :)