Xinerama

[Jon TURNEY]

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)

[1]
http://sourceforge.net/mailarchive/forum.php?thread_name=48F0B732.2040100%40dronecode.org.uk&forum_name=cygwin-ports-general


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/