> > I thought that the support for 832x624 resolution went into the
> > source, but when I 've tested Allens new Quadra-kernels, I could 
> > only run X in 640x480.
>
> Sometime in the last month or so, this seems to have been broken (I think
> that the problem exists in recent -current kernels as well, or at least
> I seem to remember others reporting it so). I believe that Scott Reynolds
> is working on Quadra video, tho.

This won' be necessary. You can read/write the offset of video base address
from/to the controller chip. It's actually not a base address but an offset
from the top of video ram. We seem to get the top of video RAM correctly.
I'm coding support for all this in intvid as we speak.

BTW, this allows for hardware page flipping support which I am also working on.
A proper rewrite of X with this in mind might accelerate things greatly.

I may code this myself but to really take advantage of things I need
a routine that properly sizes the VRAM. We're making alot of assumptions
about the state of video at boot. For instance, we assume that intvid
is the console and set the intvid address to be videoaddr. The beginning
of VRAM is listed in the dev notes for all machines. All we need do is
put those in a table. We also list the size of vram as videosize which is
simply the number of bytes in the current resolution. If I'm ever going
to support multiple resolutions I *need* to know how much VRAM total is in the
machine. I suggest the following:

Save the beginning of VRAM in the machine info intvid structure. Also,
store the absolute end of VRAM as shown in dev notes. Then run a
probe loop that goes from the top of VRAM to the end of VRAM, checking
for memory aliasing, every 128k. Then store the size someplace.
There are some sticky wickets with machines like the IIsi/IIci that
share VRAM with DRAM but I think we can special case these machines
in some way.

I may code this if nobody else has any objections.