> >Nice theory, but wrong. :-)
> >
> >Both X and dt should be looking to the kernel (via an ioctl()), which in
> >turn has extracted information from the card.  I don't see any place where
> >either application could pick up the information passed in from the Booter
> >on a NuBus video card.

> Doesn't the NuBus code check the values by asking the card and then filling
> in the grf struct? Too advanced for it's own good :)

In Nubus video case, the kernel fakes the grf structure after boot. If
you are running colorkit kernel, it changes the mode and then reads
the video parameters for a given mode, given monitor, from the ROM.
Even in this case it uses few bytes of information in mac68k_vrsrc_vec
to load info for the correct display. I found 16 different
display/page_counts data areas on my TFB card. I guess that
information is passed from the booter.

> >(However, internal video does indeed use this information!)
> >
> >The ite (console) driver uses the Booter values, so it's not surprising
> >that it sees the extra space.
> 
> Soon even this won't be true. The code I have now can probe the sense lines
> and know what monitor is on the port and figure out the resolution that way.
> That's a much better way to do it anyway. :)

I would like to look at your code sometime. Could you send me the
pointers to your code? 

	Taras Ivanenko.