Re: [gtk-list] Re: Multiple Display support in GTK+?

[raster redhat com]

On 11 Apr, Jim Harmon shouted:
->  raster@redhat.com wrote:
->  > 
->  > On 11 Apr, Alan Shutko shouted:
->  > ->  >>>>> "R" == raster  <raster@redhat.com> writes:
->  > ->
->  > ->  R> On 11 Apr, Jim Harmon shouted:
->  > ->
->  > -> -> To use the second display in most situations, all you have to do is
->  > -> -> drag the window you want to appear on the slave display from the
->  > -> -> master display and drop it.
->  > ->
->  > ->  R> no - this may onyl work under limited circumstances: 1. both
->  > ->  R> displays must contain the same set of visuals, 2: the program does
->  > ->  R> not rely on the current root window id for things it is doing...
->  > ->
->  > ->  Well, I think he was talking about multiple displays as all except X
->  > ->  implement them.  But I was wondering what it would take for your above
->  > ->  restrictions to go away.  For example, BeOS allows multiple desks of
->  > ->  different resolution and depth, and you can just drag them between.
->  > ->  Is there any hope of extending X such that this can be done?
->  > 
->  > Highly doubtful. Apps rely on the settings they obtain on startup of bt
->  > depth, visuals to use etc. - under X it is the apps responsability to
->  > use the dit depths available - there is no "virtual RGB" abstraction in
->  > X like Java. It would in theory be possible if Xservers were written as
->  > virutal-24bit servers that dvertised to clients as beig 24bit, and thne
->  > the Xserver handled dithersing,remapping etc. to the display when
->  > needed.. so the Xserver becomes a virtual 24-bit engine.. that eithe
->  > maps directly to 24bit if you run it or to 15/16bpp or to 8bpp with
->  > some palette instituted and preferably wiht some form of dithering...
->  > but this itself is a huge task... and I don't see it hapening in a
->  > hirry.. but this would allow transefing between multiple bit-depths,
->  > because as far as the app is concerned both screens are stil 24bpp.
->  
->  The first implementation of two-monitor multiheadedness I'm familiar
->  with was on VMS based systems with proprietary video subsystems.
->  
->  The hardware was responsible for identifying which display to put
->  graphic data on, based on the position of the user's cursor on a
->  digitizer.
->  
->  The two screens acted as one virtual screen 2x's as wide a single CRT.
->  
->  In fact you could drag a window across the gap in the two monitors and
->  display the image 1/2 left and 1/2 right across the gap.
->  
->  This idea was brought to UNIX under SystemVr3/4 in the window managers
->  themselves.  As long as the system identified and installed the
->  dual-monitor configuration, the window manager simply used the system
->  configurations and let you use both monitors as a single virtual
->  display.  
->  
->  This included twm and X11 window managers, among ohters, and was back in
->  1987, so the theory you're describing has been in practice, at least in
->  my experience, for over 10 years.

In X you cannot have windows span 2 screens on a multi-head display.
they are efectivel like 2 different displays.. they just happen to go
through the same Xserver. This is completely removed form a window
manager and its functions. 

->  The HARD thing (by way of complicating the driver settup seemed to have
->  been SEGREGATING the two displays to act independantly of each other.
->  
->  Then, in 1992 or 3 I was witness to the installation of Winnt3.1Beta
->  running on two displays.
->  
->  IT'S treatment is not a "virtual" single monitor, but a MANDATORY one. 
->  Infact, the "intro" login tile refused to appear anywhere but the exact
->  center of the gap between the two monitors, so logging in was often
->  frustrating, if you didn't know which field the cursor was in on bootup.
->  
->  I'm sure that's been fixed since.
->  
->  So, all implementations, from mainframe-VAX based systems to UNIX based
->  workstations to desktop PCs and MACs that I've experienced in the last
->  15 years implement a "master/slave" video subsystem for multi-
->  headedness, at least at the hardware level (how else will the system
->  know where "upper left" is?) and in UNIX, the "0" video device *is* the
->  master.

until X11R6.4 X treated each monitor/sreen as a separate screen with
each having is 0,0 co-oe att he top left - under X - there may be some
X implimentations that can treat both screesn as "one big display" but
this is not the standard way of doing multi-head - at least not
currently under X11R6.3 and earlier.

->  The software may -or may not- be intelligent enough to use the hardware
->  options available.

if X provided one big wide display software wouldnt have to be
intelligent... it just woudl find a very wide display.. x woudl handle
the rest. X software has to be intelligent to handle X's current system
that does have severe limitations.

->  And since GTK is an application library, that relies on the OS for the
->  ability to use the video system available, the only reason it wouldn't
->  be able to take advantage of multi-headedness is if the OS is in some
->  way crippled, or you only have one video card.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/