---------- Forwarded message ----------
Date: Mon, 12 Jan 1998 16:28:15 -0500 (EST)
From: Michael R Zucca <mrz5149@cs.rit.edu>
To: Avatar <bshayn1@gl.umbc.edu>
Subject: Re: Color X

> 	I'm no programmer, but is there anything I can do to help get
> color video for those of us less fortunate users with internal video?

There's not much you can do but wait or buy a video card.
Can't buy a video card? You may ask "What am I waiting for?" here's some
info:

I'm the guy currently working on internal video and I've gotten quite far
with what I'm doing but there have been hold-ups and I'm in the midst of
working on my Masters in C.S. so I've had to put intvid aside for a little
bit.

However, here's roughly what's going on so people know where intvid stands
at the moment:

Adding intvid support to NetBSD is a complex business for two reasons:
lack of documentation of internal video hardware, and the need to construct
a "real" video driver for NetBSD.

The first part I'm actually doing pretty well with. I've put together
enough info on the IIci/IIsi, IIvx, and Quadra machines to write drivers.
This covers 90% of the dekstop machines NetBSD users use. The remaining
10% are the LCIII, Quadra 630, and Quadra AV. On the first two I have a
pretty good idea of how the hardware works but, particularly on the 630,
I am having trouble finding the base address of the video controller and
the CLUT/DAC hardware. I *am* working on the problem, though. Then there's
the Quadra AV which I am still attempting to understand (I have, however,
figured out how the CLUT/DAC hardware works but cannot change modes or
resolutions yet).

The second part is the most important and requires some explaining. I have
designed an API for Mac video that allows me to code a very small number of
functions that touch the hardware (things like reloading the palette or
switching resolutions). When I discover how the hardware on a machine works I 
code the small set of functions for that machine. This leaves me with a
few short C files for each type of internal video. These pieces all get used
by a universal "software" driver. This driver deals with the drugery of
dealing with the IOCTL calls used by programs like X to do things like
switch modes, etc. So the software driver effectively translates the API
presented by the IOCTL interface into the API used by the hardware drivers.

Each part has two specific hold-ups associated with it:

On the hardware end: I was attempting to separate depth switching from
resoultion switching in an attempt to speed up the release of my first
intvidtest2 kernel but I found out that depth switching and resolution
switching are intrinsically tied together on the Quadra hardware. This means
that I have to update the hardware API to deal with resolution switching
and I have to gather timing data for the Quadras. I also had some problems
with the IIci/IIsi Macs when it came to depth switching. I recently managed
to borrow a IIci from a friend and I'll work on that problem when I get
some time.

On the software end: Scott has informed me the we will soon move away from
the grf/ite combination that we use for graphics drivers and consoles.
Instead, we're moving to the more modern fb/wscons combination. This
means big changes in the software driver and there are other issues
involved concerning how the software driver should work.

Because of the software problem I have decided to take the following
action: gather all the remaining data I need to get the Quadra and IIsi/IIci
hardware working and leave the update of the softare driver until after
the switch to fb/wscons. When we switch I will have hardware drivers
ready and then I simply have to re-tool the software driver to fit the
new fb/wscons model.

So what can you expect? I'd say look for a release of the first intvidtest2
kernel sometime after we switch to fb/wscons. That kernel will minimally
support IIsi/IIci, IIvx, and Quadras. If the time to fb/wscons is long
enough I might also have the time to figure out how the 630 and Quadra AV's
work.

I know its been a long wait so far but I feel that I'd rather put something
in the kernel tree that is going to have some holding power. I'd like
the intvid support to be "done right" the first time. I appreciate your
continuing patience and I hope you can hold out a little longer.

Thanks!

Here's my TODO list in roughly order of importance:

- Grab the values on the IIsi/IIci and finish RBV driver
- Get the timing information from the Quadras
- Update the hardare API to deal with multiple resolutions and
  finish the Quadra DAFB driver.
- Debug a 16bpp gamma problem on the IIvx
- Find out the base address of the Quadra 630
- Figure out how the blazes the Quadra AV does depth and resolution switching
- Write an LCIII driver
- Confer with Scott about how fb/wscons is going to work
(Expected release of a fb/wscons kernel)
- Adapt software driver to fb/wscons
- Possibly unify the NuBus/Intvid drivers
- Release the first intvidtest2 kernel
- Write a 630 Valkyrie driver
- Write an AV CIVIC driver
- Think about writing a PowerBook video driver