Subject: Re: Making X work on MFB
To: None <ad@fionn.sports.gov.uk>
From: maximum entropy <entropy@zippy.bernstein.com>
List: port-pmax
Date: 05/04/1999 14:20:37
>Date: Tue, 04 May 1999 12:58:47 +0100
>From: Andrew Doran <ad@fionn.sports.gov.uk>
>
>maximum entropy wrote:
>> 
>> This patch allows Xpmax to run on the turbochannel mfb.  Without this,
>> it doesn't work at all.
>
>Run, but not work. The patch would work fine on an 8-bit cfb... mfb
>only has 1 plane, not 8. The cfbSetVisualTypes() is bogus. I suspect 
>the mfb Xserver never worked properly in the first place.

Yes.  It now runs, and provides approximately the same level of
functionality as the old Xcfbpmax did.  I agree that it should be
corrected to know that there's only 1 plane, but all my attempts to do
so failed.

My goal was to get something shipped with 1.4 that is at least usable.
As far as I know there has never been a release of NetBSD/pmax where
both the text console and the X display were usable with an MFB.
Getting this fix into 1.4 is a big win.

Someone with more of a clue can now make it correct, if possible,
after 1.4 is shipped.

Do you have all the hardware that's needed to work on this?

I'm not sure what you meant by the statement "The cfbSetVisualTypes()
is bogus."  My patch _removes_ the call to cfbSetVisualTypes() because
that's the primary reason the X server wouldn't run at all.

In the original code, the middle argument to cfbSetVisualTypes() was
the biggest problem.  From looking at other code, that argument is
supposed to be a mask.  So

cfbSetVisualTypes(1, StaticGray, 8);

should have been:

cfbSetVisualTypes(1, 1<<StaticGray, 8);

But that still didn't produce a usable display.  Neither did any of
the following:

cfbSetVisualTypes(8, 1<<StaticGray, 1);
cfbSetVisualTypes(8, 1<<StaticGray, 8);
cfbSetVisualTypes(8, 1<<PseudoColor, 8);

By just removing that section of code, I ended up with a display that
worked as well as Xcfbpmax did.  I'm no X guru, but I don't think any
simple call to cfbSetVisualTypes() is going to do the right thing.
There seem to be too many assumptions buried in the code about
relationships between the number of bitplanes, the number of available
colors, and the number of bits per pixel that just aren't true on MFB
hardware.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.