frankk@cwi.nl (Frank Kuiper) (11/19/90)
I'm having a problem with OpenWindows 2.0, running on a Sun 4/110 with OS 4.0.3. When I start OW 2.0, using the command (shell script) ``openwin'' and all default rc and init files (that is, no .Xdefaults, .xinitrc and .openwin-init specified in the $HOME directory), I see an error message printec "on the console" as there is no console window yet. The message in this case is: Unable to open /etc/filetype Have you run install_filemgr? My problem is not the above message itself, but the fact that in no way I am able to clear the screen from that message! I can do a ``refresh'' in the ``Utilities >'' sub-menu, to no avail. If I do a /bin/clear-colormap, the *entire* screen becomes white. But then I can't get my OW environment back (``refresh'' doesn't help). Starting up a SunView Program (in OpenWindows) leaves the error messages on the screen. Now, my idea is that somewhere, somehow the framebuffer get's written to, but can not be cleared again by either olwm or sunview. The environment used *does* work on Sparcs running 4.1 or 4.0.3. The error message(s) do get displayed, but a simple ``refresh'' will get rid of them. I know there's a difference in framebuffers between Sparcs (/dev/cgthree) and the 4/110 (/dev/cgfour) and I've correctly set the $FRAMEBUFFER variable in both cases. I'm confused. Please e-mail me, as I don't regularly read this list. Thanks a bundle in advance. -- Frank Kuiper . ___ Internet: frankk@cwi.nl _][__| | AppleLink: HOL0042 <_______|-1 Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch. O-O-O
lee@sq.sq.com (Liam R. E. Quin) (11/30/90)
frankk@cwi.nl said that he had a problem whereby error messages appeared on
his screen when he ran openwin, and he couldn't erase them, since they were
on the monochrome frame buffer.
Although I sent him mail, it turns out that there are several good solutions.
(1) Run openwin with errors redirected:
openwin 2> /tmp/xerrs.liam
and then inside a console window I run
tail -f /tmp/xerrs.liam
This is the worst solution, although it does work.
(2) Once openwin has started, you can control the other display with
switcher -e 0
to turn it off, and
switcher -e 1
to turn it on (you don't want to do the second one, I expect!)
This has the advantage of working if you typed "openwin" and then realised
too late the problem... I certainly don't like waiting ages for openwin to
start again if I do this!
(2) Heather Rose of Sun gave by far the best solution:
openwin -dev /dev/cgfour0 -dev /dev/bwtwo0
will make openwin use both screens -- you can move the mouse-pointer off
the edge of the colour screen and onto the monochrome one.
You'll want to run
olwm -display unix:0.1
if you use olwm -- twm knows about the other frame buffer and uses it
automatically anyway.
Perhaps this will alleviate some aggravation for others.
Lee
--
Liam R. E. Quin, lee@sq.com, SoftQuad Inc., Toronto, +1 (416) 963-8337engstrom@SRC.Honeywell.COM (Eric Engstrom) (12/20/90)
[Sorry to repost nearly the entire previous message, but it was a long time ago, and I want to give some context...] In article <mumble mumble> lee@sq.sq.com (Liam R. E. Quin) writes: > frankk@cwi.nl said that he had a problem whereby error messages appeared on > his screen when he ran openwin, and he couldn't erase them, since they were > on the monochrome frame buffer. [(pseudo-)solution #1 deleted :-)] > (2) Once openwin has started, you can control the other display with > switcher -e 0 > to turn it off, and > switcher -e 1 > to turn it on (you don't want to do the second one, I expect!) > This has the advantage of working if you typed "openwin" and then realised > too late the problem... I certainly don't like waiting ages for openwin to > start again if I do this! > (2) Heather Rose of Sun gave by far the best solution: > openwin -dev /dev/cgfour0 -dev /dev/bwtwo0 > will make openwin use both screens -- you can move the mouse-pointer off > the edge of the colour screen and onto the monochrome one. > You'll want to run > olwm -display unix:0.1 > if you use olwm -- twm knows about the other frame buffer and uses it > automatically anyway. This (# 3) is what I have been TRYING to do on a Sun 3/60C [mumble, curse, curse]... At first, I did what the docuementation (OpenWindows Version 2; Installation and Start-Up Guide; Revision A, of 11 June 1990) told me to do (pages 18-20): 1) I created the device file /dev/bwtwo0. 2) modified my .xinitrc file to include the following lines eval `$OPENWINHOME/bin/svenv -env -display :0.0` olwm -display :0.0 & eval `$OPENWINHOME/bin/svenv -env -display :0.1` olwm -display :0.1 & (the first and third lines are so I can run SunView applications on those "screens") 3) started OpenWindows: % openwin -dev /dev/fb -dev /dev/bwtwo0 Now I get _THREE_ "screens", the first is color an the other two seem to be the console (i.e., they show the text of console from when I started OW) These two "extra" screens are off the color one to the right and top. Also, the two extra screens have no cursor. Since #3 didn't work, I went looking for a possible solution. Found the referenced message and tried the following: 3b) % xinit ~/.xinitrc -- xnews -dev /dev/cgfour0 -dev /dev/bwtwo0 ^^^^^^^ This didn't work either (I still get three screens). I also tried using twm instead of olwm, tried leaving the two "eval" lines out of my .xinitrc file, an I even tried an old Ojibway cerimonial dance :-), but nothing seemed to work. If anyone has ANY suggestions, I'd really appreciate them... (for completeness: Sun 3/60C, Sun OS 4.0.3, OW Ver. 2.0) Thanks much, Eric +--------- Eric Engststrom, Honeywell SRC | ARPA: engstrom@src.honeywell.com | [DISCLAIMER: UUCP: {umn-cs,ems,bthpyd}!srcsip!engstrom | My own opinions - 3.1415 = MAIL: 3660 Technology Drive, Mpls, MN | orgainically grown] Phone: (612) 782-7318 |