From <http://xquartz.macosforge.org/trac/ticket/796#comment:50>

Comment (by alexanderdewing@…):

So I've done quite a bit of digging into this bug and am almost done with
patches. Here's the issue: X11's coordinate system starts from the top
left corner of the box that contains all of the displays. OS X uses the
bottom left. So when you add a monitor that moves the X11 origin without a
comparable shift in the OS X origin, windows can 'move' from your point of
view. When you plug a new monitor in, xquartz-wm checks to see if the
window overlaps the new displays, but does move them if they're out of the
total bounding boxes. Unfortunately, somewhere in the X11 code (afaik),
different displays are treated separately when in 'separate spaces' mode,
so even if a window is in display A's bounding box, if it is 'attached' to
display B it will not be drawn and manifest as this offscreen bug. These
origin issues should only occur when you add a screen above or to the left
of your existing screens.

What should happen is that the windows stay stationary when a new monitor
is added/removed (of course the ones from the unplugged monitor should be
shifted somewhere, currently to the top left corner of the primary screen
). This, however, requires some persistent identifier to match heads to
their physical equivalents. This should be fairly simple, but has been
causing me a headache. The existing code picks the primary monitor as the
closest origin to (0,0), but it's tougher for the remainder. This could be
done approximately by matching resolutions/color depth/etc, but the
CGDirectDisplayID (which is  equal to the NSScreenNumber) will change
based on each new configuration (i.e. plug in B and A will become C.
Unplug B and C reverts to A). As far as I've been able to discover, there
is no way to load EDID data (probably the best bet?) and match it to a
head. If any of you have ideas, I am more than open. Once this piece is
fixed, the remainder of my code should be ready.

Also, I have a good workaround now. You can install wmtrl from homebrew,
and use this python script to move things around:
https://gist.github.com/sephamorr/447b15d30180bc151f623f07e87b0c81 . Hope
this is helpful.

One of the MacOSForge tickets provided a test script: http://pastebin.com/Pf2F3m29

Created attachment 124200 [details]
Reproduction case from MacOSForge Ticket

Dear Jeremy,

I'm also suffering from this problem, as I insist using several X11 applications (sometimes this is forced by my remote working on Linux machines, hence I have no choice).

I would suggest to add some option in the Xquartz Window menu (now only allowing to close, minimize or zoom a window) to allow the user to change the positioning of the window.  With some attempt, it should be possible to make it appear in the correct monitor.

Thanks,
Diego

We're seeing a variation of this. A new monitor on the right of an iMac will cause Xwindow applications like ours (AFNI) to disappear, but only if the menu bar has been moved away from the original monitor to the right secondary monitor. The default placement put the windows in negative coordinates (wmctrl -> -1920,xxx), but even trying to force the window coordinates to small positive x,y locations (0,227) doesn't work. The windows start off in a legitimate place, the screen flashes, and the windows move into an unreachable limbo (visible but undraggable icons with F10). The only way to get these back, as others have noted, is to turn off dual monitor mirroring. Switching the menu bar produces a variety of entertaining results. xeyes and xclock will usually work properly, but these switch around with the monitor configuration. For most, this is easily worked around but very confusing.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/764.