> > more than a year old...) color server already does that.  It tries to
> > init the video mode into 8-bit mode first, and if it fails, it runs as
> > though the video mode is init'ed in 1-bit B&W mode through the ioctl()
> > call.

^^^^
This is the right way to do it. Actually, a better way would be to ask
the modelist IOCTL since that's available on all machines. If we add
support for modes other than 8 and 1 bit it would be nice to just use the
mode we're in. Better yet, it would be even nicer to switch to the modes
requested on the command line too.

> > BTW, can we expect the color grf ioctl() API will remain the same in
> > future developments?
> 
> I guess we have to ask Paul Goyette and Michael Zucca, they are

I can't speak for Paul but I think he stuck to the grfioctl API. I am
also using it so that I can use color X as a test platform. However,
I find the Apple interfaces a little clunky and incomplete. It might be
the right time to switch to a new, clean interface. Unfortunately, I'm
not 100% sure what that would be since most video interfaces I've seen
are clunky and incomplete :-)

The big question is what to do when I add functionality for *resolution*
switching. I was thinking along the lines of the linux-pmac idea of
having fixed mode numbers but I've been looking more and more at letting
user-land have more control. Perhaps both would be good, especially since
we're going to have to do support for cards through the ROMs and the
Mac OS DRVR calls use mode numbers instead of values like vertical back
porches and the like.

> working hard on color support. I can not do much now... I made the
> original interface to be as close as possible to Mac interface but it
> may be better to use, say, SUN interfaces for ioctl() if keyboard and
> mouse devices are sufficiently similar. Then there will be no need for
> a separate set of patches, we can use the patches from the sun port.

I've been looking at the Solaris interfaces we use for our Ultras here at
school. It's a fairly nice interface as far as resolutions go but it's
a little weird in some other respects.

We'll see. Even if I change the interface I'll likely keep the Mac OS
style IOCTLs in for compatability's sake. That way we can depricate them
later when they fall out of use (like the HPUX style calls we're "using"
now).