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