Ok folks., here's the deal on advanced internal video support.

Right now, I'm waiting for two things:
1. The next stable kernel rev
2. To get a local internet provider so I don't have to spend a million dollars
downloading kernel source.

#2 should happen soon and I would imagine that #1 will too.

I've also decided to go with a physical driver ala MkLinux to start with
rather than proceeding directly to the ROMs. I've got code right now on the
Mac side that can change video modes and set the CLUT using just hardware
registers on my IIvx. My hardware is surprisingly similar to the 100 series
PowerMacs as seen in the MkLinux source. The ROM driver may come but it
seems infinitely more complex than the physical driver to code because
it requires seriously changing the way the kernel deals with some memory
mappings and preserving some serious memory addresses across a boot.

Advantages to coding a physical driver include:
- It's code you can change. No dependance on possibly buggy ROM code.
- The video harware registers can be mapped in at will anywhere in RAM by
  the kernel. ROM drivers rely on stuff being in Mac order.

Here are general goals:

1. Get basic B/W working for virtually everone. It seems to me that a few
people still don't have internal video even at the most basic level right now.
This is ashame because all that is usually needed is to kluge in the screen
base and size at boot. I've got tech notes which I can use to put most machines
on. I'd also like to add support to the basic driver so that it fakes up
support for the ioctl's in the NuBus video code. That way, everyone can
use the same X code and what-not. In other words, "basic" video will simply
look like a NuBus video card that supports only 1-bit mode.

2. Code up an "advanced" IIvx video driver that is compatible with Taras's
NuBus video code. This will be physical driver code. I'm going to make this
as general as I can so that new machines can be coded in easily.

It seems to me that most machines work on the same video principles with a
few exceptions. These "wacky" machines (Quadra 950's, 630's, Powerbooks and
that ilk) will either need their own code or have to wait for a ROM driver.
However, I feel that even these machines work the same way. They simply have
their hardware addresses in different spots.

3. If anybody's machine still doesn't work I might consider a ROM driver. This
might be necessary for some Powerbook monitor ports to function. Either that
or code could be added to make even this stuff work on a physical level.

Some optional extras:
- Booter options to pick which video device is grf0
- Check the Monitor control panel's PRAM record and find out who grf0 should be
- Add 16 bit mode console support if it isn't already in 1.2

Thanks for support folks!



_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________