Bug 95405 - Spaces: XQuartz windows disappearing between monitors
Summary: Spaces: XQuartz windows disappearing between monitors
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 2.7.8 (xserver-1.16.4)
Hardware: Other All
: medium normal
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
Depends on:
Reported: 2016-05-15 07:32 UTC by Marco Scabbiolo
Modified: 2019-05-23 18:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Reproduction case from MacOSForge Ticket (2.88 KB, text/plain)
2016-05-31 07:44 UTC, Jeremy Huddleston Sequoia

Description Marco Scabbiolo 2016-05-15 07:32:14 UTC
I'm using OS X "El Capitan" 10.11.3 on a Mac Book, and i usually use double monitors while working. Using Inkscape, that runs only through XQuartz, and having the monitors on "Use as separate display", i open a file from the Finder, and that file is associated to Inkscape, so XQuartz starts, and Inkscape too. The program starts, and i can see the icons in the dock, but i can't find any window, anywhere, even if i go to mission control the windows are missing from all of the desktops. I have to close XQuartz, set the display to run as "mirror", and then open the file again. That way the windows show up normally.

It's really annoying, specially when working with design stuff, that you can't take advantage of having two screens.
Comment 1 Jeremy Huddleston Sequoia 2016-05-29 21:14:02 UTC
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.
Comment 2 Jeremy Huddleston Sequoia 2016-05-31 07:42:41 UTC
One of the MacOSForge tickets provided a test script: http://pastebin.com/Pf2F3m29
Comment 3 Jeremy Huddleston Sequoia 2016-05-31 07:44:26 UTC
Created attachment 124200 [details]
Reproduction case from MacOSForge Ticket
Comment 4 Diego 2016-06-15 07:41:51 UTC
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.

Comment 5 DanielGlen 2016-10-31 19:59:47 UTC
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.
Comment 6 GitLab Migration User 2019-05-23 18:30:53 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.