Re: Multiple Display support in GTK+?

[Jim Harmon <jharmon telecnnct com>]

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.

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.

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

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.
-- 
   Jim Harmon                           The Telephone Connection
jim@telecnnct.com                          Rockville, Maryland