Mon Nov 24 01:53:00 GMT 2008

Yaakov (Cygwin Ports) wrote:
> Looking further into Xinerama, I think I brushed it off too early.  It
> is *very* widely supported[1], and while XRandR is supposed to replace
> it, actual implementation and usage may be some time off.
> I also think that there may be some potential flaws in windowed
> multiplemonitor mode that Xinerama support would fix.  While the current
> behaviour makes sense in multiwindow mode, I'm not sure that it does in
> windowed mode.  Since X window managers have no sense of what is really
> happening in that case, placing a dialog in the centre of the X display
> could easily land on the seam between two monitors.  (I know, I tried
> it.)  With Xinerama support, however, they would have the necessary
> information to DTRT.

Actually, -multiwindow mode is equally deficient.  If we presented the the 
monitors as separate screens to X (rather than one large screen which spans 
the entire Windows virtual desktop), X apps could do sensible placement with 
their windows also)

> I think that the implementation may be simpler than we thought.  To see
> the situation as it stands:
> 1) Build and install xineramaproto;
> 2) Remove the --disable-xinerama flag from xorg-server and rebuild;
> 3) Build and install libXinerama;
> 4) Remove --without-xinerama from xdpyinfo and rebuild.

This part is fine with me

> For this example, on my single-head system I launched XWin with:
> X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0
> This gives :0.0 and :0.1 side-by-side.  If you have a multihead system,
> you could just as easily run:
> X +xinerama -nodecoration -screen 0 @1 -screen 1 @2
> Now, let's see what xdpyinfo has to say:
> $ xdpyinfo -ext XINERAMA | tail
> [snip]
> XINERAMA version 1.1 opcode: 128
>   head #0: 640x480 @ 0,0
>   head #1: 640x480 @ 0,0
> AFAICS that implies that the X geometry overlaps.  Indeed, if you run an
> X client, both screens show exactly the same thing, but only screen 0
> accepts input.  Compare this to -xinerama, where each screen is
> completely independent from the other, as if you were running :0 and :1.

Yes, I think what I was trying to say back here [1], is that there isn't much 
value in enabling Xinerama until there is code in the server to set the 
monitor layout somehow.

> On Linux, after defining the Screens, you must define their relationship
> in ServerLayout, e.g.[2]:
> Section "ServerLayout"
>     Identifier  "Simple Layout"
>     Screen "Screen 2"
>     Screen "Screen 1" RightOf "Screen 2"
>     InputDevice "Mouse1" "CorePointer"
>     InputDevice "Keyboard1" "CoreKeyboard"
> EndSection
> So if we were to add additional parameters to the -screen flag, e.g.:
> X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0
> - -rightof 0

The problem is that these native windows containing server screens are 
movable!  Xinerama can't deal with dynamic changes to the layout (whereas I 
think XRandR will be able to)

I'm not sure there's a need for any additional command line parameters.  We 
can imply that screen 1 (in your example) is to the right of screen 0 from the 
  co-ordinates it's given.

In "-fullscreen -multimonitor" or "-multiwindow" mode, we could use the 
Windows GetMonitorInfo() API to discover the monitor geometry (it's perhaps an 
acceptable limitation that the server will need to be restarted to notice any 
changes to this)


Unsubscribe info:
Problem reports:

More information about the Cygwin-xfree mailing list