I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to : 1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user). At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the : 0 socket when the socket should increase based upon the number of logged in users? This is potentially a problem with multi-user systems where X11 may be needed. Merle
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend). Merle On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to : 1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify? I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget? Thanks, Jeremy On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast- user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
I have a bad feeling that this is fallout from my xcb changes... if this is true, let me know and I'll rewrite that code (again). On Dec 16, 2007, at 1:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
Thanks, Jeremy
On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
It is true. Your xcb changes broke this... but I'm going to be ditching most of server_main.c anyways in favor of integrating more tightly with xinit... so once that's done, I'll look into figuring out the right way to handle this in xinit.c (or if you know how, then by all means jump in =))... --Jeremy On Dec 16, 2007, at 05:47, Ben Byer wrote:
I have a bad feeling that this is fallout from my xcb changes... if this is true, let me know and I'll rewrite that code (again).
On Dec 16, 2007, at 1:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
It surprised me as well that a default clean Leopard install updated to 10.5.1 worked with multiple users running the xserver. Both from within their environments were utilizing a DISPLAY of /tmp/launchd- xxxxx/:0 however, xxxxx was different for each user which I'm guessing is somehow why it really worked. I tried it a couple of times to make sure I wasn't just seeing something that sometimes worked and sometimes didn't, but it worked every time I tried. As soon as I started adding the x.org update packages, it broke. Since it worked with the original Leopard X11, I did not file a bug report at Apple, but just on macosxforge. If there is something specific you would like me to try and test to help isolate the problem, let me know. Merle On Dec 16, 2007, at 4:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
Thanks, Jeremy
On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ahh... Our first (known) regression! Fix it, fix it! There are only a few small changes done to server_main.c since leopard's release. Here they are: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=f543cb8fbb3d921... http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=dc2fb323ee11f08... I honestly don't see how this would make it break! This is the only real change (everything else is just commenting, ifdefs, and white space): - if (conn == NULL) return FALSE; + if (xcb_connection_has_error(conn)) return FALSE; undoing that change still causes a problem. I am noticing the 'run by launchd for fd1' appearing in my console log. It seems to be listening on both unix:0 and the launchd socket (ie, setting DISPLAY to /tmp/launchd-... works just as setting DISPLAY=:0 once the server is running). So the key is probably in just telling it to not listen to the unix socket if launchd picks it up. Isn't that logic in xtrans? I'm using the latest git of xtrans. --Jeremy On Dec 16, 2007, at 06:53, Merle Reinhart wrote:
It surprised me as well that a default clean Leopard install updated to 10.5.1 worked with multiple users running the xserver. Both from within their environments were utilizing a DISPLAY of /tmp/launchd- xxxxx/:0 however, xxxxx was different for each user which I'm guessing is somehow why it really worked. I tried it a couple of times to make sure I wasn't just seeing something that sometimes worked and sometimes didn't, but it worked every time I tried.
As soon as I started adding the x.org update packages, it broke.
Since it worked with the original Leopard X11, I did not file a bug report at Apple, but just on macosxforge.
If there is something specific you would like me to try and test to help isolate the problem, let me know.
Merle
On Dec 16, 2007, at 4:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
Thanks, Jeremy
On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at : 0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard- coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
I was testing this again with the X11 included with Leopard and this is what I see after X11 is up and running in two different accounts, merle and testme. testme% ls -la /tmp/ total 16 drwxrwxrwt 11 root wheel 476 Dec 16 13:01 . drwxr-xr-x@ 6 root wheel 204 Dec 16 11:32 .. -r--r--r-- 1 merle wheel 11 Dec 16 12:59 .X0-lock -r--r--r-- 1 testme wheel 11 Dec 16 13:01 .X1-lock drwxrwxrwt 2 merle wheel 136 Dec 16 13:01 .X11-unix srwxrwxrwx 1 merle wheel 0 Dec 16 12:18 com.hp.launchport drwx------ 2 merle wheel 102 Dec 16 12:18 launch-4hKjbV drwx------ 2 testme wheel 102 Dec 16 12:19 launch-5F6kkF drwx------ 2 merle wheel 102 Dec 16 12:18 launch-7Z6e7z drwx------ 2 testme wheel 102 Dec 16 12:19 launch-Bpwd9y drwx------ 2 merle wheel 102 Dec 16 12:18 launch-RxHKBP drwx------ 2 testme wheel 102 Dec 16 12:19 launch-UTIeyp drwx------ 2 merle wheel 102 Dec 16 12:18 launchd-146.fUrw5l drwx------ 2 testme wheel 102 Dec 16 12:19 launchd-210.x7HrLe testme% ps -axww | grep -i x11 316 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 317 ?? 0:01.02 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/merle/.Xauthority :0 334 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 335 ?? 0:00.63 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/testme/.Xauthority :1 352 ttys002 0:00.00 grep -i x11 So, it would appear that in the original Leopard X11, that X11.app is somehow seeing that it should use a different display. Merle
What's the contents of /tmp/.X11-unix? What happens if you do: DISPLAY=:0 xterm inside (in this case) an xterm on the merle account? On Dec 16, 2007, at 12:00, Merle Reinhart wrote:
I was testing this again with the X11 included with Leopard and this is what I see after X11 is up and running in two different accounts, merle and testme.
testme% ls -la /tmp/ total 16 drwxrwxrwt 11 root wheel 476 Dec 16 13:01 . drwxr-xr-x@ 6 root wheel 204 Dec 16 11:32 .. -r--r--r-- 1 merle wheel 11 Dec 16 12:59 .X0-lock -r--r--r-- 1 testme wheel 11 Dec 16 13:01 .X1-lock drwxrwxrwt 2 merle wheel 136 Dec 16 13:01 .X11-unix srwxrwxrwx 1 merle wheel 0 Dec 16 12:18 com.hp.launchport drwx------ 2 merle wheel 102 Dec 16 12:18 launch-4hKjbV drwx------ 2 testme wheel 102 Dec 16 12:19 launch-5F6kkF drwx------ 2 merle wheel 102 Dec 16 12:18 launch-7Z6e7z drwx------ 2 testme wheel 102 Dec 16 12:19 launch-Bpwd9y drwx------ 2 merle wheel 102 Dec 16 12:18 launch-RxHKBP drwx------ 2 testme wheel 102 Dec 16 12:19 launch-UTIeyp drwx------ 2 merle wheel 102 Dec 16 12:18 launchd-146.fUrw5l drwx------ 2 testme wheel 102 Dec 16 12:19 launchd-210.x7HrLe
testme% ps -axww | grep -i x11 316 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 317 ?? 0:01.02 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/merle/.Xauthority :0 334 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 335 ?? 0:00.63 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/testme/.Xauthority :1 352 ttys002 0:00.00 grep -i x11
So, it would appear that in the original Leopard X11, that X11.app is somehow seeing that it should use a different display.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
On X11 included with Leopard: merle% ls -laF /tmp/.X11-unix/ total 0 drwxrwxrwt 2 merle wheel 136 Dec 16 15:40 ./ drwxrwxrwt 11 root wheel 476 Dec 16 15:41 ../ srwxrwxrwx 1 merle wheel 0 Dec 16 15:40 X0= srwxrwxrwx 1 testme wheel 0 Dec 16 15:41 X1= FYI, I can manually launch, in the second user, the X11-2.1.1 package X11.app with the :1 parameter and if I set DISPLAY to :1, then it will work. But that is like the Tiger X11. Looking in /tmp/.X11-unix/ after manually launching X11.app (2.1.1), I see the same two sockets as on the original Leopard X11. Merle On Dec 16, 2007, at 3:33 PM, Jeremy Huddleston wrote:
What's the contents of /tmp/.X11-unix?
What happens if you do: DISPLAY=:0 xterm
inside (in this case) an xterm on the merle account?
On Dec 16, 2007, at 12:00, Merle Reinhart wrote:
I was testing this again with the X11 included with Leopard and this is what I see after X11 is up and running in two different accounts, merle and testme.
testme% ls -la /tmp/ total 16 drwxrwxrwt 11 root wheel 476 Dec 16 13:01 . drwxr-xr-x@ 6 root wheel 204 Dec 16 11:32 .. -r--r--r-- 1 merle wheel 11 Dec 16 12:59 .X0-lock -r--r--r-- 1 testme wheel 11 Dec 16 13:01 .X1-lock drwxrwxrwt 2 merle wheel 136 Dec 16 13:01 .X11-unix srwxrwxrwx 1 merle wheel 0 Dec 16 12:18 com.hp.launchport drwx------ 2 merle wheel 102 Dec 16 12:18 launch-4hKjbV drwx------ 2 testme wheel 102 Dec 16 12:19 launch-5F6kkF drwx------ 2 merle wheel 102 Dec 16 12:18 launch-7Z6e7z drwx------ 2 testme wheel 102 Dec 16 12:19 launch-Bpwd9y drwx------ 2 merle wheel 102 Dec 16 12:18 launch-RxHKBP drwx------ 2 testme wheel 102 Dec 16 12:19 launch-UTIeyp drwx------ 2 merle wheel 102 Dec 16 12:18 launchd-146.fUrw5l drwx------ 2 testme wheel 102 Dec 16 12:19 launchd-210.x7HrLe
testme% ps -axww | grep -i x11 316 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 317 ?? 0:01.02 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/merle/.Xauthority :0 334 ?? 0:00.03 /usr/X11/X11.app/Contents/MacOS/X11 335 ?? 0:00.63 /usr/X11/X11.app/Contents/MacOS/X11 -auth / Users/testme/.Xauthority :1 352 ttys002 0:00.00 grep -i x11
So, it would appear that in the original Leopard X11, that X11.app is somehow seeing that it should use a different display.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
I forgot to check this out earlier. Once I use the bash shell (I use tcsh by default), the command below just launches an xterm as one would expect. However, DISPLAY inside the xterm is :0.0. There is no change in /tmp/.X11-unix. Also, other X11 apps are launchable without issue from this new xterm. Merle
What happens if you do: DISPLAY=:0 xterm
inside (in this case) an xterm on the merle account?
This is odd -- on my system, starting up X11 using multiple users logged in at the same time works just fine. Then again, the debugging printfs I added don't even seem to be running at all, so I really have no idea what's happening on my Frankenstein-X11 system -- I'll have to try this at work tomorrow. FWIW, .X0-lock is the lock file that corresponds with /tmp/.X11-unix/ X0. The server-main code is supposed to automatically find the first available "normal display" number and use it. Before, that code was apparently too conservative (if it saw that socket there, it assumed it was still active, and always picked the next display) -- but this meant that if your X server died and you restarted it, you'd end up with display :1 instead of :0. Now, it apparently doesn't correctly detect that the socket is still active ... ever ... On Dec 16, 2007, at 1:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
Thanks, Jeremy
On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at :0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard-coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
Your comments prompted me to play a bit more. On the default Leopard X11, if I kill X11 (I would force quit it), the /tmp/.X*-lock file would remain behind. Thus, the next time starting the server, it would create a new higher increment lock file as you described. However, with the X11-2.1.1 package, killing X11 (again force quit) would remove the /tmp/.X*-lock file. I don't know if this helps (I think I'm just confirming what you were saying), but there is definitely something different between the two versions on the death of the xserver. Merle On Dec 16, 2007, at 8:18 PM, Ben Byer wrote:
This is odd -- on my system, starting up X11 using multiple users logged in at the same time works just fine. Then again, the debugging printfs I added don't even seem to be running at all, so I really have no idea what's happening on my Frankenstein-X11 system -- I'll have to try this at work tomorrow.
FWIW, .X0-lock is the lock file that corresponds with /tmp/.X11-unix/ X0. The server-main code is supposed to automatically find the first available "normal display" number and use it. Before, that code was apparently too conservative (if it saw that socket there, it assumed it was still active, and always picked the next display) -- but this meant that if your X server died and you restarted it, you'd end up with display :1 instead of :0.
Now, it apparently doesn't correctly detect that the socket is still active ... ever ...
On Dec 16, 2007, at 1:45 AM, Jeremy Huddleston wrote:
I think the problem stems from our using the default lock file: / tmp/.X0-lock ... I don't see why the original Leopard would've worked for you, so can you please check that out and verify?
I'll try to fix this up as I rework the startup stuff... if you haven't already, would you mind filing a bug for it for me, so I don't forget?
Thanks, Jeremy
On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
The original Leopard X11 did not have this problem. I don't have a Leopard with the version just prior to X11-2.1.1 at this point in time to determine if it was X11-2.1.1 where the problem occurred or not (I can probably get there by the end of the weekend).
Merle
On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
I've been doing a bit more testing with X11-2.1.1 and find that the autolaunching stuff doesn't work if one user already has the Xserver started. At that point, any other user logging in via fast-user switching is not able to then use X11 (attempting to set DISPLAY to :1.0 and manually start X11.app winds up in an infinite loop with Xquartz still trying to talk to the server at : 0.0 which is owned by the other user).
At this point in time, I have not been about to find a workaround that would allow more than one user to utilize X11.app at the same time. Could this be because launchd is explicitly hard- coded to look at the :0 socket when the socket should increase based upon the number of logged in users?
This is potentially a problem with multi-user systems where X11 may be needed.
Merle
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
participants (3)
-
Ben Byer
-
Jeremy Huddleston
-
Merle Reinhart