Subject: Re: more OSFA stuff
To: None <armenb@moof.ai.mit.edu>
From: Ken Nakata <kenn@synap.ne.jp>
List: port-mac68k
Date: 06/01/1998 11:38:26
On Sun, 31 May 1998 11:25:32 -0400,
Armen Babikyan <armenb@moof.ai.mit.edu> wrote:
> Hello,
> 
> There was just some talk about the broken colors on machines using the OSFA
> color xserver (in my case,  on a quadra700 with GENERIC#0 1.3.1 kernel). I
> tried disabling all the color extensions in MacOS, but that doesn't seem to
> be doing a bit of good - the color "difference" is the same (xsetroot
> -solid blue is making the screen background green consistently, as opposed
> to random colors).
> 
> Did anyone find a way to get around the broken colors?

In what bit depth?  The OSFA server does color:

	1) if ROM driver is available via SLOTMAN kernel or video_lkm,
	2) or else if the screen is in 16 bit per pixel mode.

In the case 1), you can do PseudoColor in 4 or 8 bpp mode, or
TrueColor in 16 bpp mode.

You can also do StaticGray in 4 and 8 bpp modes:

	1) if ROM driver is available and you so choose via XDEVICE
	envar,
	2) or else if you set screen bit depth in 4 or 8 and in grays
	in prior to booting NetBSD.

These features are documented in the README file as Colin replied.

> Incidently, the broken colors are not only showing up on internal video,
> but on the nubus monitor, which is using the color lkm.  The color changes
> in both monitors are also the same.

Besides the video_lkm defficiency in handling multiple monitors that
Colin mentioned, I have never been able to do much testing on the
server running with multiple monitors attached, since I don't have a
NuBus video.

And I have to confess that I have carelessly overwritten my OSFA
server code by a sup run (I forgot to mv hw/netbsd/mac68k to
hw/netbsd/mac68k.OSFA and hw/netbsd/mac68k.orig to hw/netbsd/mac68k
before running sup).  Not everything was lost but most of them were,
including the -dev option and XDEVICE handler...  Sorry.

Well, some things in the server are broken so, eventually I was going
to clean it up and replace it anyway...  Next time, I'll try to build
it against 1.3.2 libs instead of current ones if I can figure out how
to do that without installing 1.3.2 over my current system.

Ken