I have just released XQuartz 2.7.10_beta1. The only changes from 2.7.9 are updates to mesa 11.2.1 and xorg-server 1.18.3. Note that as with the 2.7.9 betas, this version is built with ASan which will help with error reporting but may have a negative impact on performance. https://www.xquartz.org/releases/XQuartz-2.7.10_beta1.html Due to an issue with akami.bintray.com not satisfying ATS requirements, you may have trouble automatically updating from 2.7.9 to 2.7.10_beta1. I've already reported the issue to bintray. If you have issues downloading the update automatically, please do a manual install. Thanks, Jeremy
Jeremy Huddleston Sequoia <jeremyhu@apple.com> writes:
I have just released XQuartz 2.7.10_beta1. The only changes from 2.7.9 are updates to mesa 11.2.1 and xorg-server 1.18.3. Note that as with the 2.7.9 betas, this version is built with ASan which will help with error reporting but may have a negative impact on performance.
I tried 2.7.10_beta1 for a couple of days, and gave up because of this odd behavior: When attempting "ulimit -c unlimited" in bash running in an xterm window under beta1, I get a "permission denied" type of error (don't have the exact wording handy). It appears that something in beta1 is forcing the hard limit for core size down to zero for subprocesses of an xterm. This doesn't happen in 2.7.9, nor when running bash under Terminal. Possibly it's a side effect of ASan, but if so, it's one that I've not seen in previous versions, and it makes XQuartz next to unusable for my daily development work. Another thing I ran into is that when keeping an X11-aware build of Emacs open within my XQuartz sessions, I find it disappears from the screen after allowing my laptop to sleep and wake from sleep. The emacs process is still there according to ps, and its window is still listed in XQuartz's Window menu, but I can't see it, nor pull it up using the Window menu item. I've now found that I can reproduce this in 2.7.9 as released, though I'm sure it was not happening last time I tried to do this a few months ago. (I might still have been on Yosemite at that point, not sure. Normally I do this with a remote emacs, which hasn't shown any sign of trouble --- it's only emacs running locally on my laptop that is problematic.) Any ideas about debugging that, or a workaround? regards, tom lane
I wrote:
Another thing I ran into is that when keeping an X11-aware build of Emacs open within my XQuartz sessions, I find it disappears from the screen after allowing my laptop to sleep and wake from sleep.
After some further experimentation, I've realized that what is happening is that the window is being redisplayed completely off-screen. In general, it seems like sleep and then wake results in all my existing windows being repositioned -- although only the first time; that is, once repositioned in a sleep/wake cycle, a window is not further affected by additional sleep/wake cycles. The extent of repositioning seems to vary depending on how the window was positioned internally. The worst case I'm seeing, with the emacs window getting repositioned totally off screen, happens with a window whose initial geometry spec is "-0+0", ie pin to the upper right corner. I don't have an explanation for why this happens with local X11 clients and not remote ones with similar geometry specs. Known problem? Should I file a ticket? regards, tom lane
On Wed, May 18, 2016 at 01:03:53PM -0400, Tom Lane wrote:
I wrote:
Another thing I ran into is that when keeping an X11-aware build of Emacs open within my XQuartz sessions, I find it disappears from the screen after allowing my laptop to sleep and wake from sleep.
After some further experimentation, I've realized that what is happening is that the window is being redisplayed completely off-screen. In general, it seems like sleep and then wake results in all my existing windows being repositioned -- although only the first time; that is, once repositioned in a sleep/wake cycle, a window is not further affected by additional sleep/wake cycles. The extent of repositioning seems to vary depending on how the window was positioned internally. The worst case I'm seeing, with the emacs window getting repositioned totally off screen, happens with a window whose initial geometry spec is "-0+0", ie pin to the upper right corner. I don't have an explanation for why this happens with local X11 clients and not remote ones with similar geometry specs.
I've seen this happen ever since switching to El Capitan. I believe Dave Borman started a thread on the topic a few months ago. -- Ken Preslan <ken@preslan.org>
participants (3)
-
Jeremy Huddleston Sequoia
-
Ken Preslan
-
Tom Lane