[Xquartz-dev] Bugfixes for 2.5.1 rc1 Xorg 1.8.1 (Re: Bugfixes for 2.5.0_rc1)

[Eeri Kask]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: WindowShape_BugDemo.c
Type: text/x-c
Size: 1865 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20100604/40de5717/attachment.bin>