Ctrl-Alt-Left/Right modifier key issues

[Eeri.Kask@…]

Put this into .xinitrc:

echo 'keycode 66 = Alt_L' | xmodmap -

so that 'xmodmap -pm' reports

Alt_L is mod1 Meta_L is mod2 Control_L is control

then there seem problems in applications with arrow-key key-combinations

Ctrl-Alt-Left Ctrl-Alt-Right

but not necessarily with

Ctrl-Alt-Up Ctrl-Alt-Down

It is easiest to observe this bug with /usr/X11/bin/twm by this minimalistic .twmrc

NoTitleFocus ShowIconManager IconManagers { "XTerm" "XTerms" "100x20-10+5" 1 } "Up" = meta | control : all : f.forwiconmgr "Down" = meta | control : all : f.backiconmgr "Right" = meta | control : all : f.nexticonmgr "Left" = meta | control : all : f.previconmgr

Open few xterm's and few non-xterm applications so both icon managers at both screen top corners have few entries. Then by the above Up/Down hot-keys jump from one iconmanager entry to the next, and by Left/Right from one iconmanager to the other screen top corner.

Next, comment out 'NoTitleFocus' and the Left/Right hotkeys stop working (Up/Down still work).

Here is a short overwiew what happens. On each client startup twm first binds the above hotkeys by XGrabKey() to client windows and runs in 'focus strictly follows mouse' mode, i.e. not sending keyboard focus to any particular client if hovering over its iconmanager entry (the X11-server runs in 'PointerRoot' mode). Commenting out 'NoTitleFocus' results in twm execute XSetInputFocus() while hovering over some particular client iconmanager entry. Therefore it looks like the latter XSetInputFocus() interacts with the prior XGrabKey(), which it probably shouldn't do, as this simple test on other, non-MacOS platforms demonstrates.

This bug is already present in X11 under MacOS-X Tiger.

Eeri Kask

[jeremyhu@…]

Since this bug is long-standing (since Tiger), it's not going to block 2.4.0

[thunderbird2k@…]

This bug applies to the shift key in combination with the arrows as well. E.g. fire up Wine its notepad and selecting text by pressing shift in combination with any of the arrows results in =, /, + or *. This is not what you see at least on Linux systems or in native Mac apps, so I think the modmap needs to be updated.

[jeremyhu@…]

weird. I just reproduced this with 2.5.1_beta1 using 'wine notepad'

xev reports that shift+arrows are sending the correct keysym, so I'm not sure why wine is going wonky.

[jeremyhu@…]

(note that no special ~/.Xmodmap is needed)

[jeremyhu@…]

<rdar://problem/7824370>

[jeremyhu@…]

We'll just blacklist these old keycodes:

​http://developer.apple.com/legacy/mac/library/documentation/mac/Text/Text-579.html

[jeremyhu@…]

​http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?id=767ae026974c0d1518bd787d7036cad3c5b6754e

will land in 2.5.1_beta2

[michid@…]

This doesn't seem to be fixed in XQuartz 2.5.3

Using shift arrow key in wine notepad should select text. It does still result in the characters mentioned by jeremyho above though.

[jeremyhu@…]

Nope, it looks fixed still:

~  $ xmodmap -pk | grep Left
    131    	0xff51 (Left)	0x0000 (NoSymbol)	0xff51 (Left)	

What is the output of the above command for you?

Also, make sure you're using XQuartz.app and not X11.app

[jeremyhu@…]

Also verified by running 'wine notepad'

[michid@…]

Works now. There was an old xmodmap file lying around I forgot about. Sorry