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

[Jeremy Huddleston]

On Jun 8, 2010, at 01:41, Eeri Kask wrote:

> Am 06/07/2010 07:38 PM, Jeremy Huddleston <jeremyhu at apple.com> schrieb:
>>>>> 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.
>>> 
>>> The problem of Xquartz ignoring or destroying xmodmap settings
>>> called in .xinitrc while executing this file on server startup.
>> 
>> 
>> This is by design.  Put your xmodmap settings into ~/.Xmodmap
> 
> 
> Sorry for the curiosity, what is the technical background to this
> design?

The problem is that we need to update our X11 keymap when the OSX keymap changes.  We used to just update the keymap and ignore ~/.Xmodmap.  Now, we update the keymap then run xmodmap afterwards to get those settings again.  It was *always* the case that anything done directly in ~/.xinitrc would be ignored on layout changes, and now we atleast retain what is in ~/.Xmodmap.

Sometime around 1.4 or 1.5, the internals were changed in a way that revealed a race condition that wasn't so prominent in the past.  Essentially, the keyboard layout queried and set in the server needs to be done before xmodmap is run (otherwise it will be squashed).  The race condition was between xmodmap running in ~/.xinitrc and the layout being set in the server.  Before the updates, the server almost always won (which was great).

I changed the layout generation to address both of these issues by always running xmodmap after generating the layout in the server.  Additionally, we do not actually set the layout until the first NSEvent is received (it may be the first keyboard related NSEvent, I forget...) which is the same place it is set when a layout change occurs (thus simplifying the code).

> The .Xmodmap suggestion is of course a solution if XQuartz had (and
> honoured) a systemwide file e.g. /usr/X11/lib/X11/xinit/.Xmodmap
> where to put XQuartz keyboard initialisations used for :0 because
> ~/.Xmodmap residing on NFS-server obviously has to work with all
> other X11 platforms too attached to it remotely; therefore there
> really is no room for XQuartz-specific stuff in ~/.Xmodmap.


You're right.  Please file a bug for this, and I'll do that for the next release-candidate.


>>> The "About X11" says  "XQuartz 2.5.1_rc1 (xorg-server 1.8.1)"  and I
>>> have to admit I don't find this setting in "Preferences" (under
>>> Cmd-,) here under Leopard 10-5-8.  Probably I am looking in the
>>> wrong place?
>> 
>> It's just in the English localizations.  See the screenshot.  (You can turn it on in the English locale, then switch back and it will remain in effect)
> 
> 
> Alternatively, is there any "defaults" command for that, or, how to
> only change Alt_L by that method?  :-)

defaults write org.macosforge.xquartz.X11 option_sends_alt -BOOL true

Unfortunately, this changes both.  I actually setup mine to have left be alt and right be mode_switch with ~/.Xmodmap ;)