Conference bulova::decw_jan-89_to_nov-90

    The simple answer is that it is not supported in the X protocol.  But a
    more interesting technical discussion involves more.  Our most common
    2-head system is a mixed-type system, i.e. 1 color, 1 monochrome. 
    Since a given window is associated with a particular visual type (in X
    terms) you can't do it.  More technically, and less x-specifically,
    the application is very tightly tied to the hardware.  The app
    explicitly specifies the pixel values to be written, and how they are
    to be interpreted.  If a window can move from a mono to a color screen,
    the interpretation changes (0/1 is black white on a mono, but may be
    blue and blue on a VSII/GPX, for example).
    
    There are internal implementation reasons as well, but the server was
    implemented the way it was because of the protocol.
    
    Does that explain it?
    
    Burns
    

>Our most common 2-head system is a mixed-type system, i.e. 1 color,
> 1 monochrome.

Burns,

I am sure you are refering to VMS/VAXstations.   I have a three-headed
all-color DS5000 here.....but maybe not that 'common' yet.

Kris...

    re: -1
    
    Bet it costs a bundle, too.
    

re: .-1

If we could convince people to use an off the shelf VGA+ multi-sync
monitor, I bet it would cost a lot less!

    Problem is that the ones that W.S. looked at would not pass european
    standards. (eg. flicker). So to get one that would, actually doesn't
    save money.
    
    Besides, in the case of the DECstation 5000, it's the CPU and graphics
    that cost. Sure, it is a lot faster than the VAXstation, but if you
    look at the analogy of a BMW 750i vs. a Subaru Legacy. The 750i is
    alot faster and has wiz bang features, but some folks can't afford it.
    The Legacy, though not a 750i, is affordable, does quite well, and
    gets better mileage. 
    
    Besides, the DECstation 5000 doesn't run VMS! (sigh)
    

RE: .5

>    Besides, the DECstation 5000 doesn't run VMS! (sigh)

In some circles, this is considered a positive feature of the DECstations.

--PSW    :-)

All of that aside, I'm curious when you say that the Mac can do this.
If true, how did they solve the technical problems?  Would an X
extension help here? 

The Mac can do it with some certain hardware restrictions. (ie: all of the
hardware has to be the same "type" (such as DPI, planes, etc)


In talking with customers regarding the dual screen system, this is one
of the questiosn that they ask.  When I answer that it's not supported
in X, that seems to satisfy them, giving me the impression that it's really
a "what a neat idea" rather than a requirement.  I suspect that it would
take considerable effort to make an X extension that handles this
properly and that considerable customer requirements would be necessary to 
justify that effort.


RE: VGA monitors.


Jeff is right, we looked at LOTS of monitors and found that they would 
certainly not sell in Europe because of flicker.  (how do those damned 
PC makers plan to deal with this anyway?)  We are, however going to sell
a small trinitron monitor with the next generation VAXstation that will
considerably lower the cost of the entry color system.  Contact me offline
if you're interested.


-bill

    An interesting note - the technical aspects of this problem have
    already been solved once... it's called UISX.
    
    The problem is solved by adding a level of abstraction - the virtual
    display.  This was done in UIS, as well as by many earlier systems.
    The virtual display defines a workstation that is independent of the
    actual output device.  A user associates a window with part, or all of
    the virtual display.  This device independence makes an application
    written for a color workstation also work for a monochrome workstation
    - or *any* type of workstation.  Any drawing operation to the virtual
    display (which, by the way does not require a display list) will be
    executed on all windows associated with it.  Aspect ratio, DPI, visual
    type, available fonts and more are addressed and solved by this
    approach.
    
    To split a "window" across multiple heads **OR** multiple WORKSTATIONS
    you simply map two "windows" to different parts of a single virtual
    display.
    
    UISX has submitted to SSB and UIS clients will run on *any* VAX/VMS
    system with DECwindows V2.0.  UISX can display on any server which
    can connect to a VMS/DECwindows client.  UISX supports virtual displays
    on any number of screens/servers from a single client and up to 16
    servers from a single virtual display.  Many UIS/VWS applications will
    run without modification or relink.  UISX has been tested on 4 and 8
    plane pseudo-color and greyscale, 24-plane direct and true-color (only
    32,768 colors are allowed at once - sorry) and monochrome systems.
    A little demo -- the QIX demo -- is in the ENET distribution account
    which demonstrates the ability to display a single virtual display
    across 4 workstations or screens - total changes to the original VWS
    application is 3 lines of code (3 window creations) and a few variables
    to direct the quadrant mapping for each window.
    
    This is offered purely to show that there is not a technical problem
    here, but that Xlib is the wrong level to address it.  This should
    be addressed in a graphics programming library or widget set, not
    by X.
    

   re: visual types and displays:

   I've only seen it from a user point-of-view, but Tresle, the window system on
Fireflys out at the SRC handle moving windows from a color to a monochrome
display just fine.  Really slick too.  It's just against the X-windows
"minimalism is everything" philosophy.

   Regardless, the problem could be solved above the xlib layer, but a lot
of people are writing code to xlib, not the toolkits, and it's solve more
problems by implementing this in the server directly under the X protocol.
I suppose you could do this by always providing PseudoColor visuals, and
mapping the color map either into a real color table, a grayscale table or
a dithering-type table of black/white pixels.  Obviously, other visuals could
be provided as appropriate.

   Add this to the list of things to be fixed in X11.

					-mjg

Alternatively or additionally, use it as an argument to discourage writing
directly in Xlib.  People know by now not to program in machine language,
and usually avoid writing in assembly language.  Sooner or later they will
see the X analogy...

	paul

    Contact Pete Kaiser at CHEESE::KAISER, his group has developed a
    two-headed workstation as a special project.