This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Xinerama


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]