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