At 10:08 AM 10/10/96, Taras Ivanenko wrote:
>> >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.
>
[snip]

>> 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. :)


Lest people forget.  What started all this was a comment about using
MaxApplZoom with MacBSD.  The ite driver uses the MAZ modified data from
the booter while the grf driver uses the card ROM/hardware info.

How do we get the grf driver to support MAZ without interfering with the
support for all the other hardware?

As always I'm just a nag with no time to spend actually doing any of this
stuff, sorry.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu