Re: Xinerama
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tracking in bugzilla: http://sourceware.org/bugzilla/show_bug.cgi?id=9762 Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl0RhoACgkQpiWmPGlmQSOhTgCfRfHXsZ8abdCS7R0kTIy9kP9I BgMAn2hgXdujdKzapx+I/3YHGQdnxe+h =cZZ9 -END PGP SIGNATURE- -- 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/
Re: Xinerama
On Sun, 23 Nov 2008, Yaakov (Cygwin Ports) wrote: 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. This caused me to suspect that I'd misinterpreted some earlier mailings. Further research increased said suspicion. I'd like to make sure I'm following the conversation correctly. On Sun, 16 Nov 2008, Yaakov (Cygwin Ports) wrote: -multiwindow means hide the root window and use the internal window manager to integrate X windows with native windows The internal window manager means the one built into cygwin-xfree? The root X-window, though invisible, can still receive X-events? -multiplemonitors means I want one big X screen for this display to span all my monitors and is on by default in -multiwindow mode All pixels are presumed to be the same physical size and shape? I remember reading somewhere that all the monitors had to have the same depth, but not any other restrictions. Messy things will happen if different monitors interpret their pixels differently? As a window has only one visual at a time, a window that straddled such monitors would look messy. Xinerama does something similar, but is more flexible? If you want -multiwindow mode, but only on 1 screen, something like XWin -screen 0 @1 -multiwindow should work. IIRC someone suggested that one might want to do multi-monitor with one monitor per X-screen. That would be easier on window managers, but would not allow moving a window from one monitor to another? As I don't expect to grow another head, this is more a matter of curiosity than anything else. -- Michael [EMAIL PROTECTED] Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be. -- 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/
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.ukforum_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/
Xinerama
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon, 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. 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. 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. 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 Perhaps there is a better syntax, but the point would be to set the geometry offset correctly so that the upper left corner of screen 1 would be 640,0. (Hopefully the input on screen 1 would work correctly then as well.) Does this make any sense? Yaakov Cygwin/X [1] http://gentoo-portage.com/x11-libs/libXinerama/RDep#ptabs [2] http://tldp.org/HOWTO/Xinerama-HOWTO/editxf86config.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkpAE4ACgkQpiWmPGlmQSNHLgCgka7kXBhmyI9FlQp1rnKdgV9k hPMAn3KQFA9HjV3a0TGvCoyb23uGxLwU =ZOjk -END PGP SIGNATURE- -- 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/
