Am 03/19/2010 09:38 AM, Jeremy Huddleston <jeremyhu@apple.com> schrieb:
So the main issues I've seen reported from 2.5.0_rc1 are:
$PATH should be reordered - Fixed locally
Display config changes result in clipped pointer events (can't move window some places) - I know a fix, checking upstream to see if it's the best fix
Xephyr and Xnest have bad keymaps - Fixed locally ... you can use these binaries: http://static.macosforge.org/xquartz/downloads/testing/Xnest http://static.macosforge.org/xquartz/downloads/testing/Xephyr
System fontconfig segfaults after updating to XQuartz - The only thing this can be is a conflict in the caches. I can't really "fix" this in an XQuartz update since it's the system fontconfig crashing
System X11.app starts as "default" X11. - You need to log out for that. I don't want to force logout in the installer.
After logging out and back in, system X11.app won't run - This is an issue with the system X11 and the fix must come from Apple.
If I missed an issue, please report it (preferably with a bug report at http://xquartz.macosforge.org). As it is now, I think I have mostly eliminated the reported issues. Thanks for testing.
Here come few too: (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? (2) xmodmap, which in previous X11-versions configured some keys out of .xinitrc now doesn't do it from there anymore, out of no apparent reason. So each day in the office now begins with running this xmodmap by hand out of some xterm; e.g. in order to change left-alt-option from mode-switch back to Alt_L, and few others. How to revert this change? (3) This is older bug: after logging in X11 starts xterm at top-left, despite the presence of ${HOME}/.xinitrc which is run too and sets up the session correctly. How to disable this xterm-starting? (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 I think this bug (or some analogous one) was reported already too. It is not sure if this is a result of upgrading to 2.5.0_rc1 or putting ForwardX11Trusted yes into /etc/ssh_config. Without this ssh-option apparently Xquartz+ssh didn't send umlauted ISO-Latin characters (which are accessed by some "modeswitch"-ed keycombination, like modeswitch+a resulting in ä) to remote X11 clients. (5) The "border-issue" shows up movement but unfortunately not yet in direction of a solution. (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... (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. :-) Greetings, Eeri Kask
On Mar 19, 2010, at 03:00, Eeri Kask wrote:
Here come few too:
(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.
(2) xmodmap, which in previous X11-versions configured some keys out of .xinitrc now doesn't do it from there anymore, out of no apparent reason. So each day in the office now begins with running this xmodmap by hand out of some xterm; e.g. in order to change left-alt-option from mode-switch back to Alt_L, and few others. How to revert this change?
xmodmap is run every time the key layout changes (including on startup). There are internal issues which make it difficult to support the old way. As it is now, if you put your changes into ~/.Xmodmap, it should be run whenever the keyboard layout gets updated (such as on startup). My guess is you were doing this differently.
(3) This is older bug: after logging in X11 starts xterm at top-left, despite the presence of ${HOME}/.xinitrc which is run too and sets up the session correctly. How to disable this xterm-starting?
1) Please transition to using ~/.xinitrc.d rather than ~/.xinitrc, so you can inherit any fixes from us. 2) defaults write org.macosforge.xquartz.X11 app_to_run /usr/bin/true
(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: http://cgit.freedesktop.org/xorg/lib/libXau/commit/?id=fc54a4f03b926dfdb590b...
I think this bug (or some analogous one) was reported already too.
It is not sure if this is a result of upgrading to 2.5.0_rc1 or putting
ForwardX11Trusted yes
into /etc/ssh_config. Without this ssh-option apparently Xquartz+ssh didn't send umlauted ISO-Latin characters (which are accessed by some "modeswitch"-ed keycombination, like modeswitch+a resulting in ä) to remote X11 clients.
Yeah, if you want to tunnel X11 over ssh, using '-Y' (same as putting ForwardX11Trusted in ssh_config) is your best bet.
(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.
(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?
(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 Thanks, Jeremy
participants (2)
-
Eeri Kask
-
Jeremy Huddleston