tek@CS.UCLA.EDU (05/29/88)
From: tek@CS.UCLA.EDU
Path: tek
Newsgroups: comp.windows.x
Subject: X11 R2 & SUN 3/60(F)C (long)
Expires:
References:
Sender: tek@CS.UCLA.EDU
Reply-To: tek@CS.UCLA.EDU ()
Followup-To:
Distribution: world
Organization: UCLA Computer Science Department
Keywords:
Well, I finally figured out how to get the switching screen for the SUN
3/60 CG4. Various people on the net have hinted, now I will actually
spill the beans.
In server/ddx/sun/sunInit.c, you need to add the following line to
sunFbData[]:
sunBW2Probe, "/dev/bwtwo1", neverProbed,
if you use the ZOIDS extension:
sunBW2Probe, "/dev/bwtwo1", neverProbed, 0, 0,
Apparently, while the CG4 on the SUN 3/110C uses /dev/bwtwo0 for its
black & white, the CG4 on the SUN 3/60C and 3/60FC use /dev/bwtwo1.
The /dev/bwtwo0 is used on the 3/60M for the black & white screen.
Now, some people on the net have claimed you have to fiddle with your
/dev/bwtwo? entries a bit to get things to work. I have tried all
combinations and have discovered that sometimes I get two screens and
sometimes I get three (ie unix:0.0, unix:0.1, unix:0.2). One of the
screens is depth 8 (color), the other(s) are the depth 1 (B&W).
Also I have found that the order that the entries appear in
sunFbData[], is the order of the screens. (Unless, you use a -dev
switch with xinit, in which case you only get one screen.) So if, CG4
is before the BW2 entries, then it is unix:0.0. When there are three
screens, either two of the three screens access the same depth 1 frame
buffer or one does not acess anything at all. When two screens access
the same frame buffer, neither screen knows about the other. This
means if you try to use both, expect strange special effects.
The case when one acesses nothing was sort of wierd. The server
definitely thinks its accessing something. It turns out it is. On my
3/60FC, I noticed that the plug for the 3/60M screen is still present.
(I have heard that this is not the case for all color 3/60s.) So I
plugged in a monochrome screen. Suddenly you have a ZAPHOD 3/60.
The mysterious nothing screen was, of course, the monochrome hardware.
In fact, when you run ZAPHOD, suddenly those cases where two screens
were the same frame buffer, disappear. One of the screens is the
monochrome hardware. The monochrome hardware corresponds to the bwtwo0
entry.
My recommendation is to reverse sunFbData[]. The order then becomes:
sunCG4CProbe, "/dev/cgfour0", neverProbed,
sunCG3CProbe, "/dev/cgthree0", neverProbed,
sunCG2CProbe, "/dev/cgtwo0", neverProbed,
sunBW2Probe, "/dev/bwtwo1", neverProbed,
sunBW2Probe, "/dev/bwtwo0", neverProbed,
With all /dev entries present, you get the following behavior: The
depth 8 screen is 0. That way your best screen is zero. A few X11
(bad) programs still cannot deal with other screens. Then screen 1 is
your flip screen (bwtwo1). Finally, screen 2 is for your extra ZAPHOD
(bwtwo0) screen.
Putting, the bwtwo's the other way confuses things. Under normal
conditions, screen 1 is the flip screen. With extra hardware, screen 1
is your ZAPHOD screen. You could use screen 2 for your flip screen
always. But why use screen 0 and 2, when the other arrangement gives
you 0 and 1.
Finally, why not put bwtwo0 before cgfour? Under normal conditions,
this would make the nothing screen as number 0. With extra hardware,
of course, 0 becomes your ZAPHOD screen. Thus, under normal conditions
you end up with using screens 1 and 2 (and us computer scientists know
everything starts with 0).
The only reservation, I have, is that SUN 3/110C owners probably use
the order as it comes in the MIT distribution. (ie bwtwo0 before
cgfour) This means that they are used to the idea of flip screen at 0
and color at screen 1 (which is the opposite of above).
OTHER COMMENTS:
When the X server first comes up, the flip screen is the one with the
broken stipple pattern.
The way the server sets things up, screen 1 is to the right and left
of 0. In ZAPHOD mode, screen 1 is to the right of 0, screen 2 is to
the right of 1 and going off 2's right edge gets you back onto 0.
Currently, the mouse routines switch screens whenever you leave the
depth 8 screen, even if you are going to the ZAPHOD screen. This means
you cannot have the color screen showing when you have the mouse on
the ZAPHOD screen. It should be set up, so that the server switches
screens only when the wrong one is showing.
USUAL CAVEATS:
I am not responsible for anything you do as the result of this
message and the resulting damages, etc.
<appropriate legalese and blah, blah, blah>
-ted ARPAnet: tek@penzance.cs.ucla.edu
UUCP: {randvax,ihnp4,sdcrdcf,ucbvax}!ucla-cs!tek