dheller@cory.Berkeley.EDU (Dan Heller) (04/06/89)
I have a feeling this has been addressed already, but I missed it. We run sun3/60's at island and have recently gotten everyone's workstation upgraded to R3. The first problem starts when people just try to run X -- it says X Server Error; No Default Frame Buffer found! and it sometimes hangs. It will work if /dev/bwtwo[01] do *not* exist. I will also work if you specify /dev/cgfour0 as the -dev option to the server (but we can't seem to figure out how to do that on the xinit command line -- only by specifying Xsun -dev ...). The reason this is an issue is that it used to work ok under R2, and also because many people switch between suntools and X. Also, in trying to start X from suntools, it just doesn't work anymore... Dan Heller <island!argv@sun.com>
dlc%vetch.c3@lanl.gov (Dale Carstensen) (04/12/89)
From article <12028@pasteur.Berkeley.EDU>, by dheller@cory.Berkeley.EDU (Dan Heller): > I have a feeling this has been addressed already, but I missed it. > We run sun3/60's at island and have recently gotten everyone's > workstation upgraded to R3. The first problem starts when people > just try to run X -- it says X Server Error; No Default Frame Buffer found! > and it sometimes hangs. It will work if /dev/bwtwo[01] do *not* exist. > I will also work if you specify /dev/cgfour0 as the -dev option to the > server (but we can't seem to figure out how to do that on the xinit > command line -- only by specifying Xsun -dev ...). > Dan Heller <island!argv@sun.com> I think we have the same problem, and I reported it to xbugs@expo.lcs.mit.edu, and to mopperman@sun.com, but after about two weeks nobody has responded. We never got a message about "No Default Frame Buffer" though, except when we tried stopping in mmap with dbx. We found by using trace (we're on SunOS 4.0.1, by the way -- 3.5 doesn't have the trace utility) that Xsun is really accepting keyboard and mouse events for the bwtwo, it just doesn't manage to get anything to the display. Moving the mouse off the edge does make the color display show up, too, which is useful if you manage to get a window manager up for the color display. But the color display is much slower than the monochrome, so we'd really like to have mono work. Also, we have another 3/60C that works fine with both monochrome and color, so it isn't impossible to fix, we just don't know if it takes a software or a hardware fix. Dale Carstensen (505)667-0849 Group C-3, MS B265 FTS 843-0849 Los Alamos National Lab dlc@lanl.gov Los Alamos, NM 87545 {cmcl2|ihnp4}!lanl!dlc
dlc%vetch.c3@lanl.gov (Dale Carstensen) (04/12/89)
> From article <11837@lanl.gov>, by dlc%vetch.c3@lanl.gov (Dale Carstensen): > > From article <12028@pasteur.Berkeley.EDU>, by dheller@cory.Berkeley.EDU (Dan Heller): > >> We run sun3/60's ... > >> ... R3. The first problem starts when people > >> just try to run X -- it says X Server Error; No Default Frame Buffer found! > >> and it sometimes hangs. It will work if /dev/bwtwo[01] do *not* exist. > >> It will also work if you specify /dev/cgfour0 as the -dev option to the > >> server (but we can't seem to figure out how to do that on the xinit > >> command line -- only by specifying Xsun -dev ...). > >> Dan Heller <island!argv@sun.com> > > ... the color display is much > > slower than the monochrome, so we'd really like to have mono work. > > ... > From: ekrell@ulysses.att.com > >From: Eduardo Krell <hector!ekrell> > > You can specify the -dev option for Xsun in xinit's command line: > > xinit -- -dev /dev/cgfour0 > > all options after "--" are passed to Xsun. > In the 3/60C with a CG4, X will start by default on the monochrome > frame buffer. If you want to start it on the color one, you can > specify the -dev option as per the example above. > > If you're using the monochrome frame buffer, make sure the bwtwo1 > device exists in /dev. We are using a .xserverrc to get the -dev /dev/cgfour0 option set for Xsun. The only reason we are doing that is because Xsun fails to display anything on /dev/bwtwo0. Xsun does not even display the gray stippled root window or the X cursor on /dev/bwtwo0. However, if we do not restrict Xsun to /dev/cgfour0 via the option, moving the mouse near the left and right edges of the screen causes the prior /dev/bwtwo0 display to flash on in place of the /dev/cgfour0 display, then the reverse when the mouse moves back to the screen from the edge. That behavior goes beyond being useless, into the realm of the disconcerting. The .x*rc files are in the workstation's user's home directory. Here's the .xserverrc: Xsun -dev /dev/cgfour0 -dev /dev/bwtwo0 And the .xinitrc we're using (the host's name is squall): uwm -d squall:0.0 -f .uwmrc& xterm -fn -adobe-courier-bold-r-normal--14-140-75-75-m-90-iso8859-1 -C Dale Carstensen (505)667-0849 Group C-3, MS B265 FTS 843-0849 Los Alamos National Lab dlc@lanl.gov Los Alamos, NM 87545 {cmcl2|ihnp4}!lanl!dlc
gckaplan@sag4.ssl.berkeley.edu (George Kaplan) (04/12/89)
In article <11869@lanl.gov> dlc%vetch.c3@lanl.gov (Dale Carstensen) writes:
] [postings from Dale Carstensen and Dan Heller about problems with Sun]
] [cgfour displays and Xsun]
] ...
] We are using a .xserverrc to get the -dev /dev/cgfour0 option set for Xsun.
] The only reason we are doing that is because Xsun fails to display anything
] on /dev/bwtwo0. Xsun does not even display the gray stippled root window or
] the X cursor on /dev/bwtwo0. However, if we do not restrict Xsun to
] /dev/cgfour0 via the option, moving the mouse near the left and right edges
] of the screen causes the prior /dev/bwtwo0 display to flash on in place of
] the /dev/cgfour0 display, then the reverse when the mouse moves back to the
] screen from the edge. That behavior goes beyond being useless, into the
] realm of the disconcerting.
We have exactly this problem on one of our Sun 3/60's. On the other
3/60 we get *only* the color screen, no monochrome (the mouse pointer
stops at the left and right edges of the screen). On this second 3/60,
in fact, the *color* screen, rather than the monochrome screen, is
:0.0. On our two color 3/110's the server works the way it's supposed
to: monochrome on :0.0, color on :0.1, the mouse "wraps" between the
two screens.
We're guessing that there's some Sun hardware version or configuration
quirk that we've never heard of. Has anyone figured out what this is?
George C. Kaplan Internet: gckaplan@sag4.ssl.berkeley.edu
Space Sciences Lab UUCP: ...!ucbvax!sag4.ssl!gckaplan
University of California (415) 643-8610
Berkeley, CA 94720dana@dino.bellcore.com (Dana A. Chee) (04/12/89)
X on a Sun 3/60
First, there are (potentially) two monochrome frame buffers on a 3/60.
bwtwo0 and bwtwo1. Bwtwo0 is the frame buffer attached to the
(optional) monochrome plug in the back, while bwtwo1 is the monochrome
plane of the cgfour frame buffer.
So, assuming that you have a 3/60C, and no optional monochrome monitor
attached also, your /dev should have bwtwo1 and cgfour0, REMOVE the
bwtwo0 because it will be found first and only cause confusion.
If you have a 3/60M, then you want bwtwo0 and no bwtwo1 or cgfour0.
Now, for standard issue X (we changed our order around) it will look
for bwtwo0, cgtwo0, cgthree0, and cgfour0 in that order. To get the
working dual screen effect, add bwtwo1 after bwtwo0 in
server/ddx/sun/sunInit.c and recompile/load the server.
So, without the addition, for a 3/60C you should have only one screen,
a color one, and with the addition, you will have two screens, a mono
at screen 0 (since that one was found first) and a color one at screen
1 (since that was next on the list).
Using xinit.
There is a bug in sunInit.c which makes it unable to handle the
multiple (colon separated) displays in the -dev option. I don't know
if an official patch will come out for it or not, but its not hard,
and I'll send one to anyone that wants it. Anyway, the method of
specifying a display to the Xsun server from xinit is:
xinit -- -dev /dev/cgfour0
So, in summary, if you want the two screen effect on your cgfour0,
remove /dev/bwtwo0, add /dev/bwtwo1 and /dev/cgfour0, patch sunInit.c
so that it looks like the example below, reload and run without a -dev
argument, and you will have mono as .0 and color as .1. If your site
(like ours) would like color as .0 and mono as .1, invert the list so
that color appears before mono.
#ifdef ZOIDS
sunFbDataRec sunFbData[] = {
sunBW2Probe, "/dev/bwtwo0", neverProbed, 0, 0,
sunBW2Probe, "/dev/bwtwo1", neverProbed, 0, 0,
sunCG2CProbe, "/dev/cgtwo0", neverProbed, 0, 0,
sunCG3CProbe, "/dev/cgthree0", neverProbed, 0, 0,
sunCG4CProbe, "/dev/cgfour0", neverProbed, 0, 0,
};
#else ZOIDS
sunFbDataRec sunFbData[] = {
sunBW2Probe, "/dev/bwtwo0", neverProbed,
sunBW2Probe, "/dev/bwtwo1", neverProbed,
sunCG2CProbe, "/dev/cgtwo0", neverProbed,
sunCG3CProbe, "/dev/cgthree0", neverProbed,
sunCG4CProbe, "/dev/cgfour0", neverProbed,
};
#endif ZOIDS
Any other questions, send me mail.
--
Dana Chee
Bellcore
MRE 2Q-250
(201) 829-4488
dana@bellcore.comkemnitz@mitisft.Convergent.COM (Gregory Kemnitz) (04/21/89)
Has anyone had experience developing with X terminals (the Xebra, NCR TowerView, NCD, GraphOn etc). If so, which one has the most thoroughly tested server (or which one has the fewest bugs in its server?)? How about performance?? Greg Kemnitz