Hi, I've been unable to resume my NX session on my MacBook Pro. The problem appears to be that NX is matching the depth list returned from XListDepths one for one with the depth list on the server that first hosted the display. With the X11 that comes with 10.4.11 and 10.5.5, the result, as printed by xdpyinfo, is: depths (7): 24, 1, 4, 8, 15, 16, 32 With 1.4.2-apple19 I get: depths (7): 24, 15, 1, 4, 8, 16, 32 Could this be changed back? I tried with the "Colors:" options in preferences set to both "Millions" and "From display" but it did not make a difference. -- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
That should really make no difference what the ordering is... What is the problem that you are having? Can you tell me how to reproduce it? On Oct 18, 2008, at 11:29, Nicholas Riley wrote:
Hi,
I've been unable to resume my NX session on my MacBook Pro. The problem appears to be that NX is matching the depth list returned from XListDepths one for one with the depth list on the server that first hosted the display. With the X11 that comes with 10.4.11 and 10.5.5, the result, as printed by xdpyinfo, is:
depths (7): 24, 1, 4, 8, 15, 16, 32
With 1.4.2-apple19 I get:
depths (7): 24, 15, 1, 4, 8, 16, 32
Could this be changed back? I tried with the "Colors:" options in preferences set to both "Millions" and "From display" but it did not make a difference.
-- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sat, 18 Oct 2008 2:16 pm, Jeremy Huddleston wrote:
That should really make no difference what the ordering is...
But it does, because nxagent (at least in the version I'm using) matches the depths one for one, as I mentioned. You may correctly note that the docs don't indicate what ordering XListDepths should return, but it is the case that it returns depths in a different order from earlier Mac X11 versions. X 1.4.2 on Linux also used the ...,15,16,32 order when I checked.
What is the problem that you are having? Can you tell me how to reproduce it?
The problem I am having is that I can't resume my NX session with 1.4.2-apple19 when I start it on an earlier Mac X11 version, and vice versa. I found the place in the nxagent code where it's doing this depth matching, so I'm pretty sure this is the problem. -- Nicholas Riley <njriley@uiuc.edu>
On Oct 18, 2008, at 12:21, Nicholas Riley wrote:
On Sat, 18 Oct 2008 2:16 pm, Jeremy Huddleston wrote:
That should really make no difference what the ordering is...
But it does, because nxagent (at least in the version I'm using) matches the depths one for one, as I mentioned. You may correctly note that the docs don't indicate what ordering XListDepths should return, but it is the case that it returns depths in a different order from earlier Mac X11 versions. X 1.4.2 on Linux also used the ...,15,16,32 order when I checked.
Right, I understand the list is different, but the order in which visuals are listed (which is directly related to the order in which available depths are listed) should not matter. If it is causing you a problem, you need to report this as a bug to NX. That being said, I would like to get to the root of your problem, since I really don't think that it's the ORDER that matters.
What is the problem that you are having? Can you tell me how to reproduce it?
The problem I am having is that I can't resume my NX session with 1.4.2-apple19 when I start it on an earlier Mac X11 version, and vice versa. I found the place in the nxagent code where it's doing this depth matching, so I'm pretty sure this is the problem.
Ok, well then can you please report this bug to the NX developers... perhaps they can provide more insight or just fix their bug. Thanks, Jeremy
On Sat, Oct 18, 2008 at 12:27:03PM -0700, Jeremy Huddleston wrote:
If it is causing you a problem, you need to report this as a bug to NX.
I don't have a support contract with NoMachine, and I don't think they accept reports from users of the free version.
That being said, I would like to get to the root of your problem, since I really don't think that it's the ORDER that matters.
Sorry for the huge URL. <http://google.com/codesearch?hl=en&q=show:4UugebcMhiI:LVCNOrkoplI:VYkNFBTXFEQ&sa=N&ct=rd&cs_p=http://mirror.cict.fr/gentoo/distfiles/nxagent-1.5.0-112.tar.gz&cs_f=nx-X11/programs/Xserver/hw/nxagent/Display.c#l1448> That shows the new depths being compared to the stored depths. If you look later on line 1618 you can see where nxagentDepths gets initialized, it's pretty clearly the direct output of XListDepths. I realize this is a NX bug, but given it very recently changed in Apple's X11, and still works the old way everywhere else I could find, would it be possible to just put it back the way it was? Thanks, -- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
On Oct 18, 2008, at 23:30, Nicholas Riley wrote:
On Sat, Oct 18, 2008 at 12:27:03PM -0700, Jeremy Huddleston wrote:
If it is causing you a problem, you need to report this as a bug to NX.
I don't have a support contract with NoMachine, and I don't think they accept reports from users of the free version.
That being said, I would like to get to the root of your problem, since I really don't think that it's the ORDER that matters.
Sorry for the huge URL.
<http://google.com/codesearch?hl=en&q=show:4UugebcMhiI:LVCNOrkoplI:VYkNFBTXFE...
That shows the new depths being compared to the stored depths.
Ok, then this is obviously not an X11 bug. Since you have access to the source, I suggest you just fix it there by maybe sorting the arrays before comparing them.
If you look later on line 1618 you can see where nxagentDepths gets initialized, it's pretty clearly the direct output of XListDepths.
This might be a good place to do the sorting.
I realize this is a NX bug, but given it very recently changed in Apple's X11, and still works the old way everywhere else I could find, would it be possible to just put it back the way it was?
It would require us to back out other fixes. Plus the fix in the client application is trivial. --Jeremy
On Sun, Oct 19, 2008 at 11:10:19AM -0700, Jeremy Huddleston wrote:
Ok, then this is obviously not an X11 bug.
Since you have access to the source, I suggest you just fix it there by maybe sorting the arrays before comparing them.
Yeah, unfortunately the NX build process is far from simple, and some of the places I have NX sessions I am not an administrator of the system, so even if I fixed it I couldn't use it. If this change is going to affect X11 on other platforms NoMachine will have to fix it eventually. (Their attention to the Mac is pretty lousy - they still don't even have an Intel native version of the client software.)
It would require us to back out other fixes. Plus the fix in the client application is trivial.
For anyone else who's affected, downgrading to X11 2.3.0 restored the behavior; I can now resume NX sessions and get work done again. Oh well. -- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
participants (3)
-
Jeremy Huddleston
-
Jeremy Huddleston
-
Nicholas Riley