Bug 92653 - El Capitan - xterms blow off screen after sleep
Summary: El Capitan - xterms blow off screen after sleep
Status: RESOLVED MOVED
Alias: None
Product: XQuartz
Classification: Unclassified
Component: quartz-wm (show other bugs)
Version: 2.7.9 (xserver-1.17.4)
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
: 94579 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-10-23 20:05 UTC by Randy Bush
Modified: 2019-05-23 18:18 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Randy Bush 2015-10-23 20:05:06 UTC
old ticket - http://xquartz.macosforge.org/trac/ticket/2180

3" rMBP mid-2014
XQuartz 2.7.8
xterm using -*-courier-medium-r-normal-*-12-*-*-*-*-*-iso8859-1

multiple desktops (née spaces), each with 12 (4x3) xterms

when it wakes from a snooze, the xterms have scattered, half of them off-screen. i can command-` cycle to the off-screen ones and ^D them, but that's about it.

Changed 9 days ago by jeremyhu@…

    Milestone set to 2.8.0
    Priority changed from Not Set to Expected
    Type changed from crash to usability

Hmm. I suspect that the issue might be that we're getting notified of a state with 0 displays attached as part of the sleep/wake cycle, and that is confusing things.

comment:3 Changed 9 days ago by randy@…

and how might i test that hypothesis? or where can i whack the notification?
comment:4 Changed 8 days ago by jeremyhu@…

Take a look at _QuartzRandRUpdateFakeModes in quartzRandR.c

If we get back a list of 0 displays, we just use a fake 800x600 one.

​http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/quartzRandR.c#n516
comment:5 Changed 8 days ago by randy@…

ok, i see that.

    if it thinks it is 800x600 would it push xterms well outside those limits?
    of course, there is a DISPLAY in the environment

    % env | grep DISPLAY
    DISPLAY=:0

    i am running binary, not source, so can not really gdb or anything useful 

is there a way to set or push the display parms you seek? and note that this was a change from yosemite to el capitan.
comment:6 Changed 8 days ago by jeremyhu@…

That DISPLAY envvar is not the one expected, but it is not related to this problem. Please make sure you're not manually setting DISPLAY anywhere.

I'd expect your windows to maybe be rearranged within the 800x600 region and then stay there when you resume.

I suggest you build from source and add logging to that function to triage further.
comment:7 Changed 7 days ago by randy@…

more symtomatic data

it affects spawned xterms a la

/usr/X11/bin/xterm -geometry 80x24+1452+680 &

but, if i micro-move that xterm using the title bar, it flashes before settling (as if it moved off the screen and then back). and then it stays stable across sleep etc. so at least i have a way to keep working.
Comment 1 David Borman 2015-11-19 15:28:11 UTC
I am also seeing this issue after upgrading to El Capitan.  I was running the same version of XQuartz, 2.7.8, on Yosemite before upgrading to El Capitan.  After upgrading to El Capitan, I re-ran the XQuartz installer.  My machine is a 2012 15" MacBook Pro, and when I come into the office I attach an external 1920x1080 display which is arranged to the left of the laptop display, and I use it as my primary display.  I normally run with "Displays have separate Spaces", but the issue also happens when that is unchecked.

The only windows that are affected are windows that have not been moved since they were created.

If I run "xwininfo" before and after, what I notice is that the Absolute upper-left X and Absolute Upper-left X values have doubled:

Before:
  Absolute upper-left X:  760
  Absolute upper-left Y:  22
After:
  Absolute upper-left X:  1520
  Absolute upper-left Y:  44

And another example:
Before:
  Absolute upper-left X:  123
  Absolute upper-left Y:  256
After:
  Absolute upper-left X:  246
  Absolute upper-left Y:  512

So it is very consistent, the absolute x-y coordinates are being doubled.

This only happens when the windows haven't been manually moved or resized from their original locations.  The conditions under which this happens for me are:

1) Start up xterms without the external display attached, then plug in the external display.
2) Start up the xterms with the external display attached, then put the laptop to sleep and wake it up.
3) Start up the xterms with the external display attached, put the laptop to sleep, unplug the external display, then wake up the laptop.

For cases 2 and 3, if after starting up the xterms I unplug and plug back in the external display, then the windows do not jump after the sleep/wakeup.  Or if I just unplug the external display before putting it to sleep, then the windows do not jump.

The only other variant is that in case #3, the windows that would have jumped off the screen to the right are instead moved to the upper left corner of the display.
Comment 2 David Borman 2016-01-25 16:08:22 UTC
(In reply to David Borman from comment #1)
> ... My
> machine is a 2012 15" MacBook Pro

It shouldn't matter, but it's a non-retina, with the 1680-by-1050 high-resolution antiglare display.

I've also reproduced the issue without any external display:

1) Start up X11, and open some xterm windows
2) Do not move the windows from their initial location.
3) Put the machine to sleep
4) Wake the machine back up.

I have my external display configured to be my main screen, to the left of my laptop screen.

Have you reproduced this issue?  If not, what additional information can I give you to help you reproduce it?  I'd really like to have this fixed.
Comment 3 Jeremy Huddleston Sequoia 2016-01-25 16:29:53 UTC
Rearrangement of the windows upon display reconfiguration has been an issue for as long as I've known.  However, I have not seen this issue when sleeping, and I don't think there is anything specific about El Capitan involved here.
Comment 4 Randy Bush 2016-01-25 19:50:06 UTC
it started when i moved to el capitan.  it is irrespective of external
monitor.  it is VERY annoying.
Comment 5 David Borman 2016-01-25 21:29:25 UTC
Here's a clean test that I just ran that exhibits the problem:

1) Install El Capitan on a new disk
   - Don't restore anything
   - Just create a single new account
2) Boot up the fresh install and log in
   - Don't connect to iCloud or anything
3) Install XQuartz 2.7.8
4) Log out and back in
5) Double click the XQuartz app to start X11
6) In the default xterm window, run the command:
    xterm -geometry 80x60+600+20 &
7) Put the computer to sleep from the Apple->Sleep menu
8) Wake it up, and the window had jumped.

OSX version: 10.11.1
XQuartz version: 2.7.8
Hardware: 2012 non-retina MacBook Pro, 1680-by-1050 high-resolution display, 16G memory

So this test eliminates any local configuration issues.  It is just a stock El Capitan install with a stock XQuartz 2.7.8 install.

Here's the before and after output of xwininfo.  Notice how the XY values for the upper left corner have doubled.

% xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xe0000d "xterm"

  Absolute upper-left X:  600
  Absolute upper-left Y:  42
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 579
  Height: 844
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +600+42  -501+42  -501-142  +600-142
  -geometry 80x60+600+20

% xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xe0000d "xterm"

  Absolute upper-left X:  1200
  Absolute upper-left Y:  84
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 579
  Height: 844
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1200+84  --99+84  --99-100  +1200-100
  -geometry 80x60--99+62
Comment 6 David Borman 2016-01-29 18:10:59 UTC
I've run some more tests.  I changed my configuration to use twm instead of quartz-wm, and when running with twm I do not see the problem of jumping windows.  For another test I also ran X11 without any window manager, and putting the machine to sleep and waking it back up did not cause the windows to jump.  I went back to quartz-wm and the problem of jumping windows came back.

I built a debug version of quartz-wm with some additional traces to see what type of events are happening.  After the sleep/wakeup, a snippet of what I see:

1/28/16 4:26:22.883 PM quartz-wm[84937]: TRACE: id: 0x140000d frame_id: 0x1000013
1/28/16 4:26:22.883 PM quartz-wm[84937]: TRACE
1/28/16 4:26:22.883 PM quartz-wm[84937]:         win_rect: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]:         dock_rect: 0,1054 1920x4
1/28/16 4:26:22.883 PM quartz-wm[84937]:         screen_rect: 0,0 3600x1058
1/28/16 4:26:22.883 PM quartz-wm[84937]:         screen_no_dock: 0,0 3600x1054
1/28/16 4:26:22.883 PM quartz-wm[84937]:         title_rect: 20,30 299x22
1/28/16 4:26:22.883 PM quartz-wm[84937]:         title_int_rect: 20,30 299x22
1/28/16 4:26:22.883 PM quartz-wm[84937]:         win_int_rect: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]:         ret: 20,30 299x306
1/28/16 4:26:22.883 PM quartz-wm[84937]: validate_position(): 20,30 ok
1/28/16 4:26:22.883 PM quartz-wm[84937]: END: <ConfigureNotify window:1a1>
1/28/16 4:26:22.883 PM quartz-wm[84937]: START: <ConfigureNotify window:1a1>
1/28/16 4:26:22.883 PM quartz-wm[84937]: x_event_configure_notify() send_event:0 event:1a1 window:1000013 x,y:40,82 w,h:299,306 bw:0 above:1400012 override:1

The first part is the tail end of a ConfigureNotify that lists all the windows, including the window that I started up at 20,30.  Right after that, another ConfigureNotify event arrives for that same window, this time at 40,82.  The X coordinate had doubled, and the Y coordinate has also doubled, plus 22 for the menu bar added to the top of the window.

So, the evidence seems to be that quartz-wm is being told of a new location for the window, it isn't originating the move.

What has always intrigued me is that the window jumping isn't random, it is a doubling of the X,Y coordinates, plus the height of the menu bar added to the top of the window.

And a difference of 2X makes me think about Retina displays.  Maybe there's a bit of code somewhere that is supposed to deal with Retina displays that is doing the wrong thing, and doubling the coordinates when it shouldn't, or not undoubling them when it should.  For another experiment, I booted up my virgin El Capitan/XQuartz-2.7.8 disk on a colleagues Retina MacBook Pro, but it exhibited the same window jumping across a sleep.
Comment 7 Jeremy Huddleston Sequoia 2016-05-29 08:49:37 UTC
*** Bug 94579 has been marked as a duplicate of this bug. ***
Comment 8 Randy Bush 2016-10-16 06:48:50 UTC
this bug is now a year old.  it is very very painful, 20-30 minutes to get al my desktops of xterms back and happy on restart.  it has continued through to el capitan and xquartz 2.79. would it help to offer a bounty?
Comment 9 haroon 2016-10-16 08:30:17 UTC
(In reply to Randy Bush from comment #8)
> this bug is now a year old.  it is very very painful, 20-30 minutes to get
> al my desktops of xterms back and happy on restart.  it has continued
> through to el capitan and xquartz 2.79. would it help to offer a bounty?

For what it's worth, I haven't had this happen at all since upgrading to Sierra.
Comment 10 Randy Bush 2016-10-16 09:12:46 UTC
> For what it's worth, I haven't had this happen at all since upgrading to
> Sierra.

ok.  finally a reason to go to sierra.  thanks.
Comment 11 MasaYan 2016-10-16 11:55:36 UTC
(In reply to Randy Bush from comment #10)
> > For what it's worth, I haven't had this happen at all since upgrading to
> > Sierra.
> 
> ok.  finally a reason to go to sierra.  thanks.

Really! Great news to hear!

I'm still waiting for one 3rd app to be updated for Sierra, and I'm looking forward to see if it's really fixed.
Comment 12 haroon 2016-10-16 13:00:26 UTC
> I'm still waiting for one 3rd app to be updated for Sierra, and I'm looking
> forward to see if it's really fixed.

I am assuming that the problem has been fixed, since my original bug report (see https://bugs.freedesktop.org/show_bug.cgi?id=94579) was marked as aduplicate of this one.

That problem has completely disappeared, and I have even reenabled "displays have separate spaces" with no issues.
Comment 13 GitLab Migration User 2019-05-23 18:18:14 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/app/quartz-wm/issues/1.


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.