I just uploaded 2.5.1_beta2 (only for Snow Leopard), and it should appear if you check for updates (assuming you're on the beta update stream), or you can use this direct link: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta2.dmg A few modules were updated including a new xterm and pixman, but the focus has been on bugfixes. This has some GLX fixes and also provides a workaround for the "borders issue". Please test it out and let me know how it handles. --Jeremy
There appears to be a problem with the display variable. Does the name have a '\r' or '\n' within it? When I try to start gnuserv (for XEmacs), XEmacs (or gnuserv?) reports that it cannot find the port ,org.macosforge.xquartz.X11:6000 The format of the error makes it appear that the path (before the "org.") ends in a line break or spaces. I get not crash report from this. I also cannot send mail to report the bug because my X-based mail software crashes (with a less-than-useful crash report). This is a four-day-old MBP 13". I am running the Beta 1 currently, and it does not have the error. Thu, 22 Apr 2010 (13:29 -0700 UTC) Jeremy Huddleston wrote:
I just uploaded 2.5.1_beta2 (only for Snow Leopard), and it should appear if you check for updates (assuming you're on the beta update stream), or you can use this direct link:
http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta2.dmg
A few modules were updated including a new xterm and pixman, but the focus has been on bugfixes. This has some GLX fixes and also provides a workaround for the "borders issue".
Please test it out and let me know how it handles.
--Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-- Too many OB-GYNs aren't able to practice their love with women all across this country. George Bush comments on why doctors should be exempt from litigation 18:54 up 21 mins, 1 user, load averages: 1.08 1.38 1.07
On Apr 22, 2010, at 16:09, robert delius royar wrote:
There appears to be a problem with the display variable. Does the name have a '\r' or '\n' within it? When I try to start gnuserv (for XEmacs), XEmacs (or gnuserv?) reports that it cannot find the port
,org.macosforge.xquartz.X11:6000
My guess is that your apps are not using a recent libX11. Are you building your own (very old) libX11 or using applications that were built and shipped with older versions of that library?
Thu, 22 Apr 2010 (23:15 -0700 UTC) Jeremy Huddleston wrote:
On Apr 22, 2010, at 16:09, robert delius royar wrote:
There appears to be a problem with the display variable. Does the name have a '\r' or '\n' within it? When I try to start gnuserv (for XEmacs), XEmacs (or gnuserv?) reports that it cannot find the port
,org.macosforge.xquartz.X11:6000
My guess is that your apps are not using a recent libX11. Are you building your own (very old) libX11 or using applications that were built and shipped with older versions of that library?
That was my first thought for XEmacs, so I recompiled it. otool showed it was pulling in the libX11 from /opt/X11/lib. I will reinstall the beta2 later today to see if I can get more debug information. Are there any things I should look for? As I said earlier, the failure did not cause a crash report, and I cannot be sure whether the failure was in XEmacs or an X-lib dylib with which it links. As for the email program crash, its report was not helpful. I will need to recompile it with debugging turned on to see exactly what function failed. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky
Thu, 22 Apr 2010 (23:15 -0700 UTC) Jeremy Huddleston wrote:
On Apr 22, 2010, at 16:09, robert delius royar wrote:
There appears to be a problem with the display variable. Does the name have a '\r' or '\n' within it? When I try to start gnuserv (for XEmacs), XEmacs (or gnuserv?) reports that it cannot find the port
,org.macosforge.xquartz.X11:6000
My guess is that your apps are not using a recent libX11. Are you building your own (very old) libX11 or using applications that were built and shipped with older versions of that library?
I reinstalled beta2 to get a listing of the errors. On my installation, the directory that holds the display is not prepended to the display's name. That appears to explain all of the errors I was seeing. In an xterm 'echo $DISPLAY' returns org.macosforge.xquartz.X11:0.0 Here is what xrdb says: /opt/X11/bin/xrdb: Invalid argument /opt/X11/bin/xrdb: Can't open display 'org.macosforge.xquartz:0.0' This is what XEmacs says (btw 'xemacs -nw' runs fine, so X is the problem); Gui error: X server not responding , "org.macosforge.xquartz:0.0" An 'echo DISPLAY=$DISPLAY' command: DISPLAY=org.macosforge.xquartz:0.0 otool -L xemacs-hg/src/xemacs (after make clean; make): xemacs-hg/src/xemacs: /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /opt/X11/lib/libpng14.14.dylib (compatibility version 16.0.0, current version 16.0.0) /opt/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0) /opt/X11/lib/libXft.2.dylib (compatibility version 4.0.0, current version 4.13.0) /opt/X11/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0) /opt/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) /opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0) /opt/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libfontconfig.1.dylib (compatibility version 6.0.0, current version 6.3.0) /opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.1.0) /opt/local/lib/libtiff.3.dylib (compatibility version 13.0.0, current version 13.2.0) /opt/local/lib/libjpeg.8.dylib (compatibility version 9.0.0, current version 9.1.0) /opt/local/lib/libesd.0.dylib (compatibility version 3.0.0, current version 3.39.0) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libfreetype.6.dylib (compatibility version 11.0.0, current version 11.0.0) /opt/X11/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libXaw.7.dylib (compatibility version 8.0.0, current version 8.0.0) /opt/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0) /opt/local/lib/libgdbm.3.dylib (compatibility version 4.0.0, current version 4.0.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libaudiofile.0.dylib (compatibility version 1.0.0, current version 1.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) /opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) When I reinstall beta1, 'echo $DISPLAY' shows /tmp/launch-uO58xc/org.macosforge.xquartz:0 The odd thing (to me) is that xterms work fine, and surely it needs to know the correct DISPLAY. Also, another poster mentioned that on his system, his display includes the directory. I have checked my startup files (.tcshrc and xstartup); neither sets the display. This is a new MBP, so there shouldn't be other things interfering, plus beta1 (and the last update release) both work. Robert Royar -- You do people a bigger favor by giving them a few skills for figuring things out than by making them slaves to one particular program. -Tari Fanderclai
On Apr 23, 2010, at 11:02 AM, robert delius royar wrote:
Also, another poster mentioned that on his system, his display includes the directory.
No problem on either my MacBook or my MacPro, both running 10.6.3 and XQuartz 2.5.1_beta2 (xorg-server 1.8.0) LZsMacPro-OSX6: ~] echo $DISPLAY /tmp/launch-wdWo9a/org.macosforge.xquartz:0
Louis Zulli <zullil@lafayette.edu> writes:
On Apr 23, 2010, at 11:02 AM, robert delius royar wrote:
Also, another poster mentioned that on his system, his display includes the directory.
No problem on either my MacBook or my MacPro, both running 10.6.3 and XQuartz 2.5.1_beta2 (xorg-server 1.8.0) LZsMacPro-OSX6: ~] echo $DISPLAY /tmp/launch-wdWo9a/org.macosforge.xquartz:0
I just ran into this same problem (and filed ticket #390 about it). Now that I re-read this thread, I notice that on 2.5.0 I have $ echo $DISPLAY /tmp/launch-Cz75dW/org.macosforge.xquartz:0 whereas in beta2 I was seeing just "org.macosforge.xquartz:0.0". So that's the source of the problem, but what could be mis-setting the environment variable? regards, tom lane
I can't reproduce this. Can you please include the output from the following: grep DISPLAY /var/log/system.log On Apr 23, 2010, at 08:25, Tom Lane wrote:
Louis Zulli <zullil@lafayette.edu> writes:
On Apr 23, 2010, at 11:02 AM, robert delius royar wrote:
Also, another poster mentioned that on his system, his display includes the directory.
No problem on either my MacBook or my MacPro, both running 10.6.3 and XQuartz 2.5.1_beta2 (xorg-server 1.8.0) LZsMacPro-OSX6: ~] echo $DISPLAY /tmp/launch-wdWo9a/org.macosforge.xquartz:0
I just ran into this same problem (and filed ticket #390 about it). Now that I re-read this thread, I notice that on 2.5.0 I have
$ echo $DISPLAY /tmp/launch-Cz75dW/org.macosforge.xquartz:0
whereas in beta2 I was seeing just "org.macosforge.xquartz:0.0". So that's the source of the problem, but what could be mis-setting the environment variable?
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Apr 23, 2010, at 08:02, robert delius royar wrote:
I reinstalled beta2 to get a listing of the errors. On my installation, the directory that holds the display is not prepended to the display's name. That appears to explain all of the errors I was seeing.
In an xterm 'echo $DISPLAY' returns org.macosforge.xquartz.X11:0.0
That is wrong. It should be something like: /tmp/launch-31i9qn/org.macosforge.xquartz:0
When I reinstall beta1, 'echo $DISPLAY' shows /tmp/launch-uO58xc/org.macosforge.xquartz:0
That is the correct $DISPLAY
The odd thing (to me) is that xterms work fine, and surely it needs to know the correct DISPLAY. Also, another poster mentioned that on his system, his display includes the directory. I have checked my startup files (.tcshrc and xstartup); neither sets the display. This is a new MBP, so there shouldn't be other things interfering, plus beta1 (and the last update release) both work.
Can you try creating a new user account: Install 2.5.1_beta2. Create a new user in User Preferences Log out as the current user and log in as the other (or use FUS) Launch XQuartz.app
Fri, 23 Apr 2010 (11:20 -0700 UTC) Jeremy Huddleston wrote:
On Apr 23, 2010, at 08:02, robert delius royar wrote:
I reinstalled beta2 to get a listing of the errors. On my installation, the directory that holds the display is not prepended to the display's name. That appears to explain all of the errors I was seeing.
In an xterm 'echo $DISPLAY' returns org.macosforge.xquartz.X11:0.0
That is wrong. It should be something like:
/tmp/launch-31i9qn/org.macosforge.xquartz:0
When I reinstall beta1, 'echo $DISPLAY' shows /tmp/launch-uO58xc/org.macosforge.xquartz:0
That is the correct $DISPLAY
The odd thing (to me) is that xterms work fine, and surely it needs to know the correct DISPLAY. Also, another poster mentioned that on his system, his display includes the directory. I have checked my startup files (.tcshrc and xstartup); neither sets the display. This is a new MBP, so there shouldn't be other things interfering, plus beta1 (and the last update release) both work.
Can you try creating a new user account:
Install 2.5.1_beta2.
OK
Create a new user in User Preferences OK Log out as the current user and log in as the other (or use FUS) Tried both Launch XQuartz.app DISPLAY=org.macosforge.xquartz.X11:0.0 in the new user account. When I use FUS, I switched back to my regular account and see DISPLAY=/tmp/launch-uO58xc/org.macosforge.xquartz:0 in terminal (without having started Xquartz.app or an X application in that account). Also, I have the Xquartz icon permanently in my dock (set that way). It shows the dot beneath it to indicate it is running. I can select the icon and get the X11 menu bar. Xterms run from it, but not my own apps (XEmacs or Alpine within an xterm.
I believe that it is also odd that the display variable is the same socket I had this morning even though I have exited Xquartz a few times and have logged out. You asked others to supply the reults of grepping system.log for DISPLAY. Here, are my results of that (I think the erroneous perios are 15:XX times: Apr 23 08:33:58 grendal [0x0-0x13013].org.macosforge.xquartz.X11[182]: X11.app: Received new $DISPLAY fd: 5 ... sleeping to allow xinitrc to catchup. Apr 23 10:00:24 grendal [0x0-0x2f02f].org.macosforge.xquartz.X11[1023]: X11.app: Received new $DISPLAY fd: 5 ... sleeping to allow xinitrc to catchup. Apr 23 10:39:49 grendal [0x0-0x46046].org.macosforge.xquartz.X11[10288]: X11.app: Received new $DISPLAY fd: 5 ... sleeping to allow xinitrc to catchup. Apr 23 15:38:31 grendal [0x0-0x93093].org.macosforge.xquartz.X11[12283]: X11.app: Received new $DISPLAY fd: 6 ... sleeping to allow xinitrc to catchup. Apr 23 15:44:39 grendal org.macosforge.xquartz.startx[12504]: X11.app: Received new $DISPLAY fd: 5 ... sleeping to allow xinitrc to catchup. Apr 23 15:53:53 grendal [0x0-0xab0ab].org.macosforge.xquartz.X11[12917]: X11.app: Could not connect to server (DISPLAY="/tmp/launch-uO58xc/org.macosforge.xquartz:0", unsetting). Starting X server. Apr 23 15:53:53 grendal [0x0-0xab0ab].org.macosforge.xquartz.X11[12917]: X11.app: No launchd socket handed off, unsetting DISPLAY Apr 23 15:55:46 grendal [0x0-0xc20c2].org.macosforge.xquartz.X11[13196]: X11.app: Received new $DISPLAY fd: 8 ... sleeping to allow xinitrc to catchup.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-- rdr
robert delius royar <x11@frinabulax.org> writes:
You asked others to supply the reults of grepping system.log for DISPLAY. Here, are my results of that (I think the erroneous perios are 15:XX times: Apr 23 08:33:58 grendal [0x0-0x13013].org.macosforge.xquartz.X11[182]: X11.app: Received new $DISPLAY fd: 5 ... sleeping to allow xinitrc to catchup.
I've been poking at this too, and I concur that system.log isn't showing any clear difference between 2.5.0 and 2.5.1_beta2. I notice that the "Received new $DISPLAY" log entry seems to be happening asynchronously relative to the other output from the server, eg compare these sequences: Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X11.app: main(): argc=2 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[0] = /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[1] = -psn_0_258111 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: Waiting for startup parameters via Mach IPC. Apr 23 18:02:46 pro org.macosforge.xquartz.startx[1596]: font_cache: Scanning user font directories to generate X11 font caches Apr 23 18:02:46 pro org.macosforge.xquartz.startx[1596]: font_cache: Updating FC cache Apr 23 18:02:46 pro org.macosforge.xquartz.privileged_startx[1295]: font_cache: Scanning system font directories to generate X11 font caches Apr 23 18:02:46 pro defaults[1624]: \nThe domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist Apr 23 18:02:46 pro org.macosforge.xquartz.startx[1596]: xauth: creating new authority file /Users/tgl/.serverauth.1596 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X11.app: Listening on socket for fd handoff: (4) /var/tmp/tmp.0.ummUPf Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X11.app: Thread created for handoff. Returning success to tell caller to connect and push the fd. Apr 23 18:02:46 pro org.macosforge.xquartz.startx[1596]: Xquartz: Handoff connection established (try 1 of 5) on fd 6, "/var/tmp/tmp.0.ummUPf". Sending message. Apr 23 18:02:46 pro org.macosforge.xquartz.startx[1596]: Xquartz: Message sent. Closing handoff fd. Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X11.app: Received new $DISPLAY fd: 6 ... sleeping to allow xinitrc to catchup. Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X11.app: do_start_x11_server(): argc=6 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[0] = /opt/X11/bin/X Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[1] = :5 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[2] = -nolisten Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[3] = tcp Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[4] = -auth Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: argv[5] = /Users/tgl/.serverauth.1596 Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: Xquartz starting: Apr 23 18:02:46 pro [0x0-0x3f03f].org.macosforge.xquartz.X11[1588]: X.Org X Server 1.8.0 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X11.app: main(): argc=2 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[0] = /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[1] = -psn_0_294984 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: Waiting for startup parameters via Mach IPC. Apr 23 18:04:27 pro org.macosforge.xquartz.startx[1858]: font_cache: Scanning user font directories to generate X11 font caches Apr 23 18:04:27 pro org.macosforge.xquartz.startx[1858]: font_cache: Updating FC cache Apr 23 18:04:27 pro org.macosforge.xquartz.privileged_startx[1295]: font_cache: Scanning system font directories to generate X11 font caches Apr 23 18:04:27 pro defaults[1886]: \nThe domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist Apr 23 18:04:27 pro org.macosforge.xquartz.startx[1858]: xauth: creating new authority file /Users/tgl/.serverauth.1858 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X11.app: Listening on socket for fd handoff: (4) /var/tmp/tmp.0.9631Cf Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X11.app: Thread created for handoff. Returning success to tell caller to connect and push the fd. Apr 23 18:04:27 pro org.macosforge.xquartz.startx[1858]: Xquartz: Handoff connection established (try 1 of 5) on fd 6, "/var/tmp/tmp.0.9631Cf". Sending message. Apr 23 18:04:27 pro org.macosforge.xquartz.startx[1858]: Xquartz: Message sent. Closing handoff fd. Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X11.app: do_start_x11_server(): argc=6 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[0] = /opt/X11/bin/X Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[1] = :6 Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X11.app: Received new $DISPLAY fd: 6 ... sleeping to allow xinitrc to catchup. Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[2] = -nolisten Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[3] = tcp Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[4] = -auth Apr 23 18:04:27 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: argv[5] = /Users/tgl/.serverauth.1858 Apr 23 18:04:27 pro org.macosforge.xquartz.privileged_startx[1295]: font_cache: Updating FC cache Apr 23 18:04:28 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: Xquartz starting: Apr 23 18:04:28 pro [0x0-0x48048].org.macosforge.xquartz.X11[1848]: X.Org X Server 1.7.6 At first I thought that was a smoking gun, but looking further back in system.log I see that in both versions that entry can happen before, during, or after the dump of the argv values. Is that expected? Maybe there's some race condition here. Some other random experimentation: * If I launch Terminal then "echo $DISPLAY" shows the correct value (with full path), even while shells inside xterms show the wrong value. In fact, I can launch an xterm *from the Terminal shell* ("xterm &") and its shell still shows the wrong value. * I thought from the above that maybe xterm itself was incorrectly editorializing on the DISPLAY value it inherited. I tried reinserting 2.5.0's /opt/X11/bin/xterm into a 2.5.1_beta2 installation, but this did not fix it. It is clear that something is changing the inherited value of DISPLAY but it's not in the xterm executable --- maybe somewhere in the X libraries? regards, tom lane
On Apr 23, 2010, at 15:22, Tom Lane wrote:
* If I launch Terminal then "echo $DISPLAY" shows the correct value (with full path), even while shells inside xterms show the wrong value. In fact, I can launch an xterm *from the Terminal shell* ("xterm &") and its shell still shows the wrong value.
Ok, then it has nothing to do with the server. That xterm is inheriting DISPLAY from its parent process (bash running in Terminal.app). Can you launch xterm from Terminal.app through gdb and break on 'setenv' ... maybe we'll get lucky and see where it's getting changed...
* I thought from the above that maybe xterm itself was incorrectly editorializing on the DISPLAY value it inherited. I tried reinserting 2.5.0's /opt/X11/bin/xterm into a 2.5.1_beta2 installation, but this did not fix it. It is clear that something is changing the inherited value of DISPLAY but it's not in the xterm executable --- maybe somewhere in the X libraries?
These are the only changes http://xquartz.macosforge.org/trac/wiki/ChangeLog I updated libxcb, and I also changed libX11 to use libxcb for transport rather than the traditional route. I bet somewhere in libxcb or libX11 there is some mangling of the DISPLAY environment variable... As a workaround for now, you can probably just copy replace /opt/X11/lib/libX11.6.dylib with the one from 2.5.0. If that works, then it is either xcb itself or the xcb bits in libX11. --Jeremy
Ok. I'm able to reproduce this now. Thanks for your help debugging. It'll be fixed in the next release. I'll try to have one this weekend or early next week since this is a fairly bit usability issue that slipped through the cracks. --Jeremy On Apr 23, 2010, at 15:48, Jeremy Huddleston wrote:
On Apr 23, 2010, at 15:22, Tom Lane wrote:
* If I launch Terminal then "echo $DISPLAY" shows the correct value (with full path), even while shells inside xterms show the wrong value. In fact, I can launch an xterm *from the Terminal shell* ("xterm &") and its shell still shows the wrong value.
Ok, then it has nothing to do with the server.
That xterm is inheriting DISPLAY from its parent process (bash running in Terminal.app).
Can you launch xterm from Terminal.app through gdb and break on 'setenv' ... maybe we'll get lucky and see where it's getting changed...
* I thought from the above that maybe xterm itself was incorrectly editorializing on the DISPLAY value it inherited. I tried reinserting 2.5.0's /opt/X11/bin/xterm into a 2.5.1_beta2 installation, but this did not fix it. It is clear that something is changing the inherited value of DISPLAY but it's not in the xterm executable --- maybe somewhere in the X libraries?
These are the only changes http://xquartz.macosforge.org/trac/wiki/ChangeLog
I updated libxcb, and I also changed libX11 to use libxcb for transport rather than the traditional route. I bet somewhere in libxcb or libX11 there is some mangling of the DISPLAY environment variable...
As a workaround for now, you can probably just copy replace /opt/X11/lib/libX11.6.dylib with the one from 2.5.0. If that works, then it is either xcb itself or the xcb bits in libX11.
--Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Apr 23, 2010, at 7:00 PM, Jeremy Huddleston wrote:
Ok. I'm able to reproduce this now.
Thanks for your help debugging. It'll be fixed in the next release. I'll try to have one this weekend or early next week since this is a fairly bit usability issue that slipped through the cracks.
--Jeremy
Yes, I now see the problem too, when I'm in an xterm: Procyon: ~] echo $DISPLAY org.macosforge.xquartz:0.0 My previous posts were based on what I got from within Terminal.app Louis
Thanks. I have a fix for it and it will be in the next beta. On Apr 23, 2010, at 17:28, Louis Zulli wrote:
On Apr 23, 2010, at 7:00 PM, Jeremy Huddleston wrote:
Ok. I'm able to reproduce this now.
Thanks for your help debugging. It'll be fixed in the next release. I'll try to have one this weekend or early next week since this is a fairly bit usability issue that slipped through the cracks.
--Jeremy
Yes, I now see the problem too, when I'm in an xterm:
Procyon: ~] echo $DISPLAY org.macosforge.xquartz:0.0
My previous posts were based on what I got from within Terminal.app
Louis
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
This should have the fix. Thanks for everyone's help reporting / diagnosing the issue. http://xquartz.macosforge.org/downloads/SL/XQuartz-2.5.1_beta3.dmg The only difference between beta2 and beta3 is this one patch. --Jeremy
Thanks, Jeremy. Works for me: Procyon: ~] echo $DISPLAY /tmp/launch-FeMhCA/org.macosforge.xquartz:0.0 On Apr 23, 2010, at 9:26 PM, Jeremy Huddleston wrote:
This should have the fix. Thanks for everyone's help reporting / diagnosing the issue.
http://xquartz.macosforge.org/downloads/SL/XQuartz-2.5.1_beta3.dmg
The only difference between beta2 and beta3 is this one patch.
--Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
This should have the fix. Thanks for everyone's help reporting / diagnosing the issue. http://xquartz.macosforge.org/downloads/SL/XQuartz-2.5.1_beta3.dmg
Only partially fixed, I'm afraid: remote clients over an ssh -Y tunnel still fall over. The complaints look like this: connect /tmp/launch-9pq5dZ/org.macosforge.xquartz:0.0: No such file or directory X connection to localhost:10.0 broken (explicit kill or server shutdown). The local-Perl-Tk case that I initially complained of in ticket 390 does work, so that's a step forward. But it's still unusable for my purposes if ssh tunneling doesn't work :-( It might or might not be relevant that $DISPLAY shows up as "...:0.0" rather than the former value of "...:0"? regards, tom lane
On Apr 23, 2010, at 9:52 PM, Tom Lane wrote:
Only partially fixed, I'm afraid: remote clients over an ssh -Y tunnel still fall over. The complaints look like this:
connect /tmp/launch-9pq5dZ/org.macosforge.xquartz:0.0: No such file or directory X connection to localhost:10.0 broken (explicit kill or server shutdown).
Yup, I'm seeing the same, after invoking ssh -Y from a local xterm: LZsMacPro-OSX6: ~] xcalc connect /tmp/launch-FeMhCA/org.macosforge.xquartz:0.0: No such file or directory Error: Can't open display: localhost:10.0
Well the change to libxcb fixed things for libxcb and libX11... too bad ssh didn't parse the screen out of $DISPLAY like it's supposed to... =/ I have a workaround for that in libX11 now: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=aae2a4a7aab26de3fa715... If we ever decide to support multiple X11 screens, we'll need to revert that (and have ssh fixed). Here's a replacement for libX11.6.dylib with the workaround: http://static.macosforge.org/xquartz/downloads/testing/libX11.6.dylib.bz2 (I won't be rolling an updated beta just to fix this... beta3 addressed the main issue, and the workaround is easy enough) --Jeremy On Apr 23, 2010, at 19:22, Louis Zulli wrote:
On Apr 23, 2010, at 9:52 PM, Tom Lane wrote:
Only partially fixed, I'm afraid: remote clients over an ssh -Y tunnel still fall over. The complaints look like this:
connect /tmp/launch-9pq5dZ/org.macosforge.xquartz:0.0: No such file or directory X connection to localhost:10.0 broken (explicit kill or server shutdown).
Yup, I'm seeing the same, after invoking ssh -Y from a local xterm:
LZsMacPro-OSX6: ~] xcalc connect /tmp/launch-FeMhCA/org.macosforge.xquartz:0.0: No such file or directory Error: Can't open display: localhost:10.0
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
OK, ssh -Y from xterm works for me now. Thanks again. Louis On Apr 24, 2010, at 12:55 AM, Jeremy Huddleston wrote:
Well the change to libxcb fixed things for libxcb and libX11... too bad ssh didn't parse the screen out of $DISPLAY like it's supposed to... =/ I have a workaround for that in libX11 now:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=aae2a4a7aab26de3fa715...
If we ever decide to support multiple X11 screens, we'll need to revert that (and have ssh fixed).
Here's a replacement for libX11.6.dylib with the workaround: http://static.macosforge.org/xquartz/downloads/testing/libX11.6.dylib.bz2
(I won't be rolling an updated beta just to fix this... beta3 addressed the main issue, and the workaround is easy enough)
--Jeremy
participants (4)
-
Jeremy Huddleston
-
Louis Zulli
-
robert delius royar
-
Tom Lane