Many thanks to those who replies to my original post concerning multiple
monitors on a SPARCstation 10. I originally stated:
>I have a customer who would like to connect several monitors to a
>sparc 10. Has anyone done anything like this? He is looking at
>up to four monitors, with a seperate display for each. It sounds
>like we could put four framebuffers in the computer to run the
>monitors. Is this pratical? How would we address the different
>screens seperately? Are they just different displays, ie- moe:0
>moe:1?
>
>Thanks in advance for any replies,
>Don
>don%bumpo@motoman.pnl.gov
The replies I got were from (I hope I don't forget anyone):
dd@mv.us.adobe.com
Brian Katzung katzung@{i88.isc, swissbank}.com
Bruce Kall Kall@Mayo.edu
John DiMarco jdd@cdf.toronto.edu
Steven A. Geyer geyer@is.morgan.com
Syed Zaeem Hosain szh@zcon.com
George D M Ross gdmr@dcs.ed.ac.uk
Peter Heimann peter@rwthi3.informatik.rwth-aachen.de
Jordan Hayes jordan@IMSI.COM
First some clarification. There was a little confusion as to what we
were attempting to do. The idea is to have 4 35 inch monitors on one
wall of a room with someone controlling what is displayed on each
monitor. Since the SPARC 10 has 4 sbus slots, and only one of those
appears to be used for a frame buffer, 4 displays seems doable. For
the most part, the displays will be static, but one of the displays
might need to show scrolling text.
The consensus seems to be that this is doable, with a possible problem
of overloading the colormap. Most of the respondents were using
X11R5 and not Openwindows to do this, and most were using 2 or 3
monitor configurations. I got the addressing scheme wrong in my
original message. To address the different displays I would use:
moe:0.1, moe:0.2, etc.
An abridgement of the responses follows (I hope none of the respondants
takes offense at the abridgement here):
dd@mv.us.adobe.com writes:
Yes, it is practical. Of course, you need an SBus expansion box if you
want to have more than 3 frame buffers.
Normally you would run a single X server and the screens would be
host:0.0, host:0.1, ...
If you want to use an MIT server, you would have to get the multiscreen
patches from Kaleb Keithley.
Brian Katzung katzung@{i88.isc, swissbank}.com writes:
I use X11R5 and tvtwm on my IPC with an add-on color adaptor, and they
automatically manage the built-in monochrome adaptor (even though I don't
have a monitor attached to it) unless you take steps to prevent it.
Dragging the mouse off the left or right edges of the screen moves it
between displays.
MAKEDEV expects a unit number for display devices (ie, "cgsix0", not just
"cgsix"), so this is probably a good sign for multiple frame buffers of the
same type.
Checking the manual pages for the desired X server and window manager
should tell you what flags you need in order to specify which frame buffers
to manage.
The display is specified as [host]:server[.display]. Your proposed
configuration would be a single server with four displays, "moe:0.0" through
"moe:0.3". You wouldn't have a "moe:1" unless moe was host for a second
X server (with a second keyboard, mouse, and more displays, which would then
be "moe:1.0", "moe:1.1", etc).
Bruce Kall Kall@Mayo.edu writes:
I currently have a triple headed display with 3 frame buffers
and 3 monitors. It is supported in openwin. 4 to my knowledge
is not.
John DiMarco jdd@cdf.toronto.edu writes:
It is indeed possible, with either Sun's openwindows or Mit X11R5, using
Kaleb Keithley's multi-screen patch. I'm typing this reply on an IPC with
three displays.
Displays are specified as: unix:0.1, unix:0.2, unix:0.3, etc. NB: unix:1,
unix:2, etc. refers to separate display+keyboards in X11 parlance.
Just add framebuffers and monitors. Easy.
Steven A. Geyer <geyer@is.morgan.com> writes:
Many of our traders use dual-headed SS10s. It works fine. In the
X Windows System, one would address the screens as:
host:0.0
host:0.1
Before you do this, consider the applications that you will be using
on the SS10. Remember, Sun's frame buffers do not provide 24 bit
graphics. ;) So, if applications hog the colormap and do not support
dynamic mapping within the application, then the colormap can get
filled up quickly.
All subsequent applications will not be able to load their own colormap
into the X server. I find that the more screen space one has, the
faster they fill their colormap. Hence, they cannot start certain
applications due to the lack of colormap space in the X server. It
is a painful catch-22 when programmers program (!^#%(*@$& ugly code.
Syed Zaeem Hosain szh@zcon.com writes:
My experience (with a GXTRA sbus card) with this was poor. The card
simply did not work cleanly for our testing with OpenWindows. Plus,
this usually (not always) means that the computer is getting four times
the load anyway. It would probably be more effective to buy four
smaller machines - in other words, if you were planning to do this on a
Sun 10/30 (access to 4 sbus slots), get 4 Classics instead. You will
get some single-process-performance-loss, but the overall result will
be better, in my opinion.
Or get 4 X-terminals if you want to stick with the existing computer.
All in all, these are better solutions. The workstations were simply
not engineered for multiple users on multiple keyboards with separate
frame buffers in my opinion.
We are typically working with CAD and heavy duty cpu
intensive environments where it was *always* better to get more
processors rather than try to get the single cpu to handle multiple
displays. In our tests with multiple graphics cards, (and multiple
keyboards/mice by the way for multiple users), we decided that the
*significant* degradation in overall performance was simply not worth
it!
Or, if you are not using cpu-intensive programs, then
X-terminals work just fine, at a very reasonable cost, and much more
flexibility! You are not running video cables all over the place;
moving the X terminals is easier; range is not as limited; etc., etc.
George D M Ross gdmr@dcs.ed.ac.uk writes:
We have several systems configured with multiple screens (including the one
I'm posting from). They work very nicely, and the extra real-estate is
extremely useful. Using X11R5 they appear as, say, moe:0.0 and moe:0.1 (I
think you can do this with OW too, but we rarely run it and I've not tried).
Note that the stock MIT R5 server can only drive one framebuffer of any
particular type. If you have two or more of the same type you'll need to
apply export.lcs.mit.edu:contrib/R5.Xsun.multi-screen.tar.Z too.
Peter Heimann peter@rwthi3.informatik.rwth-aachen.de writes:
We have done this with two cgsix framebuffers. If we start OpenWindows with
openwin -dev /dev/fb -dev /dev/cgsix1 right
the left monitor is display machine:0.0, and the right machine:0.1. If you
move the cursor off the right edge of the left monitor, it will reappaer on
the right monitor. You can't move windows between the displays.
I never tried this with four framebuffers. At least the SunOS 4.1.3 manual
claims that it works.
jordan@IMSI.COM (Jordan Hayes) writes:
We regularly run multiple
monitors on our Sparc/10 (up to 4) and Sparc/2 (up to 3) machines. It
works great! X11R5 (with patches) finds all the monitors and
applications that can deal with it (all ours do) can provide lots of
real estate with only one keyboard/mouse set.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:44 CDT