Skip to content
This repository has been archived by the owner. It is now read-only.
Switch branches/tags
Go to file
Cannot retrieve contributors at this time
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component
2015-10-11 01:11:54 -0700
2015-10-23 17:34:28 -0700
2015-10-23 17:34:28 -0700

XQuartz 2.7.8_rc1 on El Capitan - xterms blow off screen after sleep

13" rMBP mid-2014 XQuartz 2.7.8_rc1 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.

only thing i can think of so far is that

urxvt*secondaryScreen: true

might be the cause. but makes no sense.

randy@… commented on Oct 11, 2015

and i presume it is really a quartz-wm issue but i do not know how to select component in this trac. apologies.

jeremyhu@… commented on Oct 14, 2015

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

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.

randy@… commented on Oct 15, 2015

and how might i test that hypothesis? or where can i whack the notification?

jeremyhu@… commented on Oct 15, 2015

Take a look at _QuartzRandRUpdateFakeModes in quartzRandR.c

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

randy@… commented on Oct 15, 2015

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
  • 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.

jeremyhu@… commented on Oct 15, 2015

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.

randy@… commented on Oct 16, 2015

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.

jeremyhu@… commented on Oct 23, 2015

Mass Edit

As you may have noticed, we have had issues with spam in trac for the past couple years. We've decided to migrate to using's bugzilla for our bug tracker (more details will be coming on the mailing lists in the next couple weeks).

I don't want us to loose valuable bug reports in the transition, so I want to make sure that any relevant open issues in this MacOSForge trac are migrated over to the new system. If you are interested in this issue, please take a few minutes to file a new bug for this issue in bugzilla. Please make sure to do the following:

  • Copy over all relevant information into that report, just in case we loose this one.
  • Set the URL field of the bugzilla report to this trac ticket's URL.
  • Paste the URL of the new bugzilla report as a comment in this ticket, and I'll close it out.

randy@… commented on Oct 23, 2015

migrated to

jeremyhu@… commented on Oct 23, 2015

  • Status changed from new to closed
  • Resolution set to Duplicate