Am 03/20/2010 03:00 PM, xquartz-dev-request@lists.macosforge.org schrieb:

...

(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.)

...

(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.

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 and things like this by means of the $HOME/.Xmodmap file.

...

(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

The variant (2) above would be the ultimate solution if it only worked on OSX-10.5.8... The problem with (1) is, that on all other OS'es I am working with the .xinitrc (which is NFS-mounted to everywhere here) method works well (and has always worked well), and they together out-vote OSX's method of now by their sole number. Nurturing two X11-startup methods in parallel is not favourable.

...

(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 looks like both ssh-parties access the same $HOME/.Xauthority file. Looking hypothetically, what happens if they both decide to exclusively lock that file, and proceed only if they both succeed, which cannot be achieved?

...

(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?

At that time 2008 I was not yet using MacOSX, and after reporting then I forgot about it. Now while upgrading to Xquartz 2.5.0_rc1 I was looking for something else but stepped in (this report and) that little program again. So I don't know if the bug is present in 2.4.x too. If it is helpful I'll put 2.4.0 back again and test. I'll tweak that little test program and then file a bug.

...

(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. Greetings, Eeri Kask P.S. Now with 2.5.0_rc1 the xclipboard (i.e. cut+paste) works even across remote ssh-tunneled X11-applications which is really great, huge thanks! :-)