Bugfixes for 2.5.1 rc1 Xorg 1.8.1 (Re: Bugfixes for 2.5.0_rc1)
Sorry for the delayed reply, in the meantime running 2.5.1 rc1 quite happily.
(1) Each time I log in (and launch X11) I am asked (sorry for sloppy English translation) something about ... "Do I want to allow remote applications to access X11, an option which can be tuned in firewall options too" ... or something. So each day in the office begins with a click on "yes, I do". How to automate this buttonclick?
My guess is that you have a 3rd party firewall installed, and you should check that software.
I'll take a look at it later, but the fact is, this behaviour appeared only a week ago after installing 2.5.0_rc1. (I am running OSX 10.5.8 --- each time I am even asked for a root password to make a change to somewhere but it apparently is discarded after each session.)
There is absolutely NOTHING in XQuartz that should be doing that. Do you have the exact text of the request (you can probably take a screen shot with cmd-shift-4).
It looks like this behaviour has something to do on Leopard with System settings / Security / Firewall (*) the third bullet-item from the top, which reads in English probably like "configure access for particular services/programs" In contrast, if I click the second item, "allow only relevant services", this problem is gone. So it looks like being MacOS/XQuartz issue (besides, I cannot think of anyone of our employees or anyone else who could be suspected fiddling with 3rd party firewalls on this machine anyways). :-)
If I remember correctly, Xorg 1.6.x (or 1.5.x, I don't know anymore) had this or analogous 'behaviour' too (i.e. on other OS'es than MacOSX) but after installing 1.7.x the 'old' behaviour appeared recovered which was a really good advancement.
One of the problems with the above suggestion is, I don't know how to implement
if test "Darwin" = "`uname -s`" then echo 'keycode 66 = Alt_L' | xmodmap - echo 'keycode 69 = Alt_R' | xmodmap - else echo 'keycode 115 = Meta_L' | xmodmap - echo 'keycode 116 = Meta_R' | xmodmap - fi
mkdir ~/.xinitrc.d cat > ~/.xinitrc.d/10-xmodmap_prep.sh <<EOF #!/bin/bash if [[ \"\$(uname -s)\" == "Darwin" ]] ; then echo 'keycode 66 = Alt_L' echo 'keycode 69 = Alt_R' else echo 'keycode 115 = Meta_L' echo 'keycode 116 = Meta_R' fi > ~/.Xmodmap EOF chmod 755 ~/.xinitrc.d/10-xmodmap_prep.sh
Unfortunately I still don't catch the idea why Xquartz has to fiddle with the keyboard from the moment on while executing .xinitrc, the above suggestion really is no solution to the "not yet identified" problem. :-)
(4) New bug: Starting remote X11 applications by
ssh -f remotehost remote-application
now apparently succeeds only with the first remote application, further applications often result in something like
Warning: No xauth data; using fake authentication data for X11 forwarding. /usr/bin/xauth: error in locking authority file /home/eeri/.Xauthority X11 connection rejected because of wrong authentication. Error: cannot open display: localhost:11.0
This works for me. It looks like your remote filesystem does not support locking. I added a fix for that last year. What version of libXau is installed on your remote system? Try updating to libXau 1.0.3:
The NFS-server (from where the $HOME filesystem comes from) has libXau 1.0.4 so it cannot be this.
It's not the NFS server that matters. It's the client side that matters. The system that you are running your X11 application on needs to have libXau 1.0.4
Accidentally the NFS-server is the X-client as well. I have to report, since upgrading to 2.5.1-rc1 really in 2-3 times I have managed to confirm your "...This works for me..." (i.e. it worked for me too!); but in contrast I count probably some 2000-3000 times it hasn't worked here.
(5) The "border-issue" shows up movement but unfortunately not yet in direction of a solution.
Yes. This bug is still present. I have no idea what is causing it or how to fix it. It's on my list of issues to bring up with other X11 developers at XDS this September... but hopefully something can get resolved before then.
Huge thanks, this issue looks like solved now!? :-)
(6) Some applications leave clutter on screen analogous to the bug I reported
http://lists.freedesktop.org/archives/xorg/2008-August/037802.html
but now without xcompmgr running. So it appears it is probably Xorg but not a compositing-extension issue...
Please file a bug report with your sample app (http://xquartz.macosforge.org)
When did you start seeing this behavior?
Now again, having observed 2.5.1 rc1 it looks like it is the AppleWM-XPlugin issue, and occurs on XShape'd clients. I.e. if running on a blank server without quartz-wm, or more precise, without AppleWM-shadows by XAppleWMFrameDraw(), all seems well, i.e. nothing unusual. For the sake of simplicity I'll attach a small demo program to this posting which shows a rectangular semitransparent frame inside the test window if running under quartz-wm and this client is not focused. If this test client *is* focused, the surrounding shadow is gone (btw. why?) and the transparent inner frame is gone too. Further, under quartz-wm, if this test client is focused, the upper corners appear rounded, if not focused, rectangular. (Looking closely it looks like here *all* X-clients shaped or not show these rectangular/rounded upper edges artefacts.) Can you confirm this?
(7) Something like once per week or few weeks the old server 2.4.? could be crashed by the ancient xless, if this has changed now remains to be observed. :-)
Do you recall the backtrace? Look in /Library/Logs/CrashReporter
Here I count twenty crash-report-files to this bug since 2009-09-29, I'll pack them together and file a bug in few days.
I am happy to report these crashes haven't occurred anymore since running 2.5.1 rc1. Really huge thanks. Greetings, Eeri Kask
On Jun 4, 2010, at 05:35, Eeri Kask wrote:
It looks like this behaviour has something to do on Leopard with
System settings / Security / Firewall
(*) the third bullet-item from the top, which reads in English probably like "configure access for particular services/programs"
In contrast, if I click the second item, "allow only relevant services", this problem is gone.
So it looks like being MacOS/XQuartz issue (besides, I cannot think of anyone of our employees or anyone else who could be suspected fiddling with 3rd party firewalls on this machine anyways). :-)
Ok, then please file a bug report at http://bugreport.apple.com as this looks like it may be an issue with the OSX firewall.
mkdir ~/.xinitrc.d cat > ~/.xinitrc.d/10-xmodmap_prep.sh <<EOF #!/bin/bash if [[ \"\$(uname -s)\" == "Darwin" ]] ; then echo 'keycode 66 = Alt_L' echo 'keycode 69 = Alt_R' else echo 'keycode 115 = Meta_L' echo 'keycode 116 = Meta_R' fi > ~/.Xmodmap EOF chmod 755 ~/.xinitrc.d/10-xmodmap_prep.sh
Unfortunately I still don't catch the idea why Xquartz has to fiddle with the keyboard from the moment on while executing .xinitrc, the above suggestion really is no solution to the "not yet identified" problem. :-)
What behavior are you suggesting is "not yet identified" ? The keyboard layout can be changed through OSX international settings, and X11 will update the keyboard layout when it detects that. You can toggle the alt key mode (mode_switch versus alt) in X11's preferences in the latest 2.5.1 rc (I forget which beta got that change, but I think it was beta2).
Accidentally the NFS-server is the X-client as well.
I have to report, since upgrading to 2.5.1-rc1 really in 2-3 times I have managed to confirm your "...This works for me..." (i.e. it worked for me too!); but in contrast I count probably some 2000-3000 times it hasn't worked here.
Well then this was probably not working for you when you had the old libXau, so it's fixed now ;)
Now again, having observed 2.5.1 rc1 it looks like it is the AppleWM-XPlugin issue, and occurs on XShape'd clients. I.e. if running on a blank server without quartz-wm, or more precise, without AppleWM-shadows by XAppleWMFrameDraw(), all seems well, i.e. nothing unusual.
For the sake of simplicity I'll attach a small demo program to this posting which shows a rectangular semitransparent frame inside the test window if running under quartz-wm and this client is not focused. If this test client *is* focused, the surrounding shadow is gone (btw. why?) and the transparent inner frame is gone too.
Further, under quartz-wm, if this test client is focused, the upper corners appear rounded, if not focused, rectangular. (Looking closely it looks like here *all* X-clients shaped or not show these rectangular/rounded upper edges artefacts.) Can you confirm this?
Weird. Can you please file a bug report at http://xquartz.macosforge.org or http://bugreport.apple.com (please attach your sample code)?
participants (2)
-
Eeri Kask
-
Jeremy Huddleston