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

Jeremy Huddleston jeremyhu at apple.com
Fri Jun 4 11:02:55 PDT 2010


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





More information about the Xquartz-dev mailing list