adamj@web5h.berkeley.edu (Adam J. Richter) (08/23/88)
Recently, somebody (was it RWS?) posted a note saying that it would be nice X servers will treat multiple screens as a single screen with multiple visuals. Don't do it. Future applications may want to use different visuals for different sub-windows, and must not be mislead into believing that two visuals coexist on the same screen, when in fact those visuals span physically disjoint screens. For example, consider a color animation program that manipulates the color map to do animation in one window, while displaying monochrome text in another window. Don't do it. The whole point of being able to put the screen number in your DISPLAY environment variable is so that you can specify the screen on which YOU want the application to appear. I have routinely used multi-headed X11 servers, and I routinely intentionally put applications on the "wrong" monitor because the other one is cluttered, or for some other reasonable reason. I want that level of control. Don't do it. The functionality of selecting the best visual or screen belongs on the client side, either as an *OPTION* in Xlib or in the toolkit. E.g., it might be reasonable if a toolkit would try to make an intelligent choice if $DISPLAY was of the format: "unix:0" but, would always be forced to display #5, if DISPLAY were: "unix:0.5" That's one way to do it. Don't touch the X server; your time would be much better spent responding to bug reports, distributing patches and releasing new distributions more frequently. Adam J. Richter adamj@zen.berkeley.edu 2600 Ridge Road ....!ucbvax!zen!adamj Berkeley, CA 94709 Home: (415)549-6379
adamj%web5h.berkeley.EDU%agate@UCBVAX.BERKELEY.EDU ("Adam J. Richter") (08/23/88)
Recently, somebody (was it RWS?) posted a note saying that it
would be nice X servers will treat multiple screens as a single screen
with multiple visuals.
Don't do it. Future applications may want to use different
visuals for different sub-windows, and must not be mislead into
believing that two visuals coexist on the same screen, when in fact
those visuals span physically disjoint screens. For example, consider
a color animation program that manipulates the color map to do
animation in one window, while displaying monochrome text in another
window.
Don't do it. The whole point of being able to put the screen
number in your DISPLAY environment variable is so that you can
specify the screen on which YOU want the application to appear. I
have routinely used multi-headed X11 servers, and I routinely
intentionally put applications on the "wrong" monitor because the
other one is cluttered, or for some other reasonable reason. I want
that level of control.
Don't do it. The functionality of selecting the best visual
or screen belongs on the client side, either as an *OPTION* in Xlib or
in the toolkit. E.g., it might be reasonable if a toolkit would try
to make an intelligent choice if $DISPLAY was of the format:
"unix:0"
but, would always be forced to display #5, if DISPLAY were:
"unix:0.5"
That's one way to do it. Don't touch the X server; your time
would be much better spent responding to bug reports, distributing
patches and releasing new distributions more frequently.
Adam J. Richter adamj@zen.berkeley.edu
2600 Ridge Road ....!ucbvax!zen!adamj
Berkeley, CA 94709 Home: (415)549-6379jim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/23/88)
> Recently, somebody (was it RWS?) posted a note saying that it > would be nice X servers will treat multiple screens as a single screen > with multiple visuals. Yes, it was Bob. He was talking about multiple screens on a single display tube, not multiple heads being driven by a single server. > Don't do it. Future applications may want to use different > visuals for different sub-windows, and must not be mislead into > believing that two visuals coexist on the same screen, when in fact > those visuals span physically disjoint screens. Two visuals can coexist on the same screen. Several of the various graphics supercomputers that are hitting the market already allow 24-bit deep DirectColor or some number of bits of PseudoColor window to be located at arbitrary locations on the screen. The particular instance that Bob was talking about was the sample server for color Sun displays that have the extra overlay plane. For those who haven't seen one in action, the current implementation provides two separate X screens on the same display tube (Zaphod mode) which toggle back and forth whenever the mouse moves off the edge of the root window. Instead of having these two separate screens, it would be much nicer to have both visuals available on one screen (if people like the extra real estate, they should use a window manager that provides rooms). This would allow monochrome applications to use the faster StaticGray visual and color applications to use a PseudoColor visual. One reason why we're interested in doing this is to see how many applications will break because they simply use the default visual instead of looking at what's available and choosing the correct one. Unfortunately, the answer is probably "a lot of them." The relevant routines in Xlib are XGetVisualInfo and XMatchVisualInfo, although I would expect various toolkits to provide alternative interfaces. Jim Fulton MIT X Consortium
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/24/88)
Date: 23 Aug 88 10:47:33 GMT
From: agate!web5h.berkeley.edu!adamj@ucbvax.berkeley.edu (Adam J. Richter)
Recently, somebody (was it RWS?) posted a note saying that it
would be nice X servers will treat multiple screens as a single screen
with multiple visuals.
I was misunderstood (by more than just you), sorry I wasn't clear.
I meant what Jim Fulton said I meant.RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/24/88)
Date: 23 Aug 88 10:47:33 GMT
From: agate!web5h.berkeley.edu!adamj@ucbvax.berkeley.edu (Adam J. Richter)
Recently, somebody (was it RWS?) posted a note saying that it
would be nice X servers will treat multiple screens as a single screen
with multiple visuals.
I was misunderstood (by more than just you), sorry I wasn't clear.
I meant what Jim Fulton said I meant.dana@dino.bellcore.com (Dana A. Chee) (08/24/88)
In article <8808231403.AA22734@EXPO.LCS.MIT.EDU> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
The particular instance that Bob was talking about was the sample server for
color Sun displays that have the extra overlay plane. For those who haven't
seen one in action, the current implementation provides two separate X screens
on the same display tube (Zaphod mode) which toggle back and forth whenever the
mouse moves off the edge of the root window.
Instead of having these two separate screens, it would be much nicer to
have both visuals available on one screen (if people like the extra real
estate, they should use a window manager that provides rooms). This would
allow monochrome applications to use the faster StaticGray visual and color
applications to use a PseudoColor visual.
I'm not sure how well this would work on the Sun, since Zaphod mode
uses two different frame buffers (the monochrome screen appears whenever
the color frame buffer is disabled -- maybe you could disable only
part of the color frame buffer to allow some of the monochrome to show
through). But anyway, this doesn't fix the problem. How do you
specify resources for a given visual type? And how do you tell the
application that you wish to use a certain type (for example, if
Zaphod mode was implemented with visuals instead of screens, I would
like my clock to run on a PseudoColor visual, but my emacs to run on
StaticGray for speed)? Will this require new command line arguments?
One reason why we're interested in doing this is to see how many applications
will break because they simply use the default visual instead of looking at
what's available and choosing the correct one. Unfortunately, the answer is
probably "a lot of them."
The relevant routines in Xlib are XGetVisualInfo and XMatchVisualInfo, although
I would expect various toolkits to provide alternative interfaces.
Lots will break, since there's no way to tell an application what you
want (most applications will run on any type)
Jim Fulton
MIT X Consortium
--
+*************************************************************************+
* Dana Chee (201) 829-4488 *
* Bellcore *
* Room 2Q-250 *
* 445 South Street ARPA: dana@bellcore.com *
* Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana *
+*************************************************************************+RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/25/88)
Date: 24 Aug 88 12:31:29 GMT
From: dana@bellcore.bellcore.com (Dana A. Chee)
I'm not sure how well this would work on the Sun, since Zaphod mode
uses two different frame buffers (the monochrome screen appears whenever
the color frame buffer is disabled -- maybe you could disable only
part of the color frame buffer to allow some of the monochrome to show
through).
There is a mask plane on the 3/60 that can be used to select between
1-bit and 8-bit on a pixel basis. There is a (new) hook in our ddx
layer that should make maintaining this mask straightforward.
But anyway, this doesn't fix the problem. <Lots of
good questions.>
No it doesn't fix a problem, it exposes one. All of your questions
are reasonable, and we have even more.black@masscomp.UUCP (Sam Black) (08/26/88)
In article <8808231403.AA22734@EXPO.LCS.MIT.EDU> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > >Two visuals can coexist on the same screen. Several of the various graphics >supercomputers that are hitting the market already allow 24-bit deep >DirectColor or some number of bits of PseudoColor window to be located at >arbitrary locations on the screen. > > ... > >Instead of having these two separate screens, it would be much nicer to >have both visuals available on one screen (if people like the extra real >estate, they should use a window manager that provides rooms). This would >allow monochrome applications to use the faster StaticGray visual and color >applications to use a PseudoColor visual. > > Jim Fulton > MIT X Consortium I agree with Jim for displays that use multiple screens to try to support both color and monochrome (or the like). But it does not deal gracefully with overlay planes. Our servers support both multiple visuals AND multiple virtual screens on the same physical display. Screen 1 supports the overlay planes on our displays. For example, our 28-plane display supports (basicallly) 4 24-plane DirectColor visuals on screen 0 (4 concurrent colormaps), and a a 2-plane StaticGray visual on screen 1 to support the 2 overlay planes. Likewise, our 12-plane display supports 1 10-plane PseudoColor visual, 4 8-plane PseudoColor visuals (subsets of the 10-plane visual to simulate 4 hardware colormaps), and a 2-plane StaticGray visual on screen 1 to support the 2 overlay planes. Graphics in the overlay planes are INDEPENDENT of graphics in the other visuals. We initially implemented the overlay planes as a separate visual, but this had problems. First of all, it created unnecessary exposure events. When an overlay window gets unmapped, the underlying graphics need not be redrawn. Implemented as a visual, it was forced to be redrawn. The other problem had to do with overlay planes in general. Since overlay planes always appear OVER the normal graphics, overlay windows always visually "obscure" graphics windows, although they may be lower in the stacking order. With separate screens, the stacking orders are disjoint, so the input focus is screen-dependent. Overall, the second screen solved all the problems that another visual would have caused. Screen jumping is not implemented in the server, but as a client (actually we have 2 clients with different interfaces). (I hope this explanation made sense.) - sam black -------------------------------------- I'm pink, therefore I'm Spam. ...!{decvax,uunet}!masscomp!black UUCP black@masscomp.com Internet --------------------------------------
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/27/88)
Date: 26 Aug 88 14:00:48 GMT
From: masscomp!black@uunet.uu.net (Sam Black)
For example, our 28-plane display supports (basicallly) 4 24-plane DirectColor
visuals on screen 0 (4 concurrent colormaps), and a a 2-plane StaticGray visual
on screen 1 to support the 2 overlay planes. Likewise, our 12-plane display
supports 1 10-plane PseudoColor visual, 4 8-plane PseudoColor visuals (subsets
of the 10-plane visual to simulate 4 hardware colormaps), and a 2-plane
StaticGray visual on screen 1 to support the 2 overlay planes.
You seem to imply that you need a visual per colormap. Can you explain
this? Why isn't it sufficient to just provide one visual and multiple
colormaps?
First of all, it created unnecessary exposure events. When an overlay window
gets unmapped, the underlying graphics need not be redrawn. Implemented as a
visual, it was forced to be redrawn.
There is no a priori reason I know of why this is required, except perhaps
that the sample server implementation might not provide adequate internal
support. Can you explain what "forced" means?
The other problem had to do with overlay planes in general. Since overlay
planes always appear OVER the normal graphics, overlay windows always visually
"obscure" graphics windows, although they may be lower in the stacking order.
With separate screens, the stacking orders are disjoint, so the input focus
is screen-dependent.
I'm again confused. Although overlay planes appear over normal
graphics, if you have per-pixel enable capability you can certainly set
the control planes so that they only appear over when they are actually
higher in the stacking order, and allow the normal graphics to show
through when they are lower. It requires appropriate hooks in some
server layers, but I don't see why it can't be done. Can you explain?