X11 keysym mapping is broken (shifted versus unshifted is wrong)
I use the X11 support in Mac OS X to run clients on my Linux server. After upgrading to Leopard I found that [shift]-e doesn't produce an uppercase "E" in those Linux X11 clients. Yet pressing [caps-lock] does results in an uppercase "E". Also, [caps-lock] produces inconsistent results for the number keys. Specifically, the "7", "9" and "0" keys produce "&", "(" and ")" while the other number keys produce their respective numbers with [caps-lock] engaged. After reverting to the Tiger version of X11 those keys behave correctly.
I have a Kinesis Advantage keyboard. It works fine with Mac OS X and Ubuntu when connected directly to the Linux server. I use a custom X11 xmodmap configuration on the Linux client when I access it via my Mac system. I include that configuration below. That xmodmap configuration works fine with the Tiger X11 implementation. It works fine with the Leopard X11 implementation with the exception of the "e", "7", "9", and "0" keys. Based on everything I've read and tried I can only conclude there is something wrong with keysym handling by the Leopard X11 server.
keycode 8 = a A
keycode 19 = b B
keycode 16 = c C
keycode 10 = d D
keycode 22 = e E
keycode 11 = f F
keycode 13 = g G
keycode 12 = h H
keycode 42 = i I
keycode 46 = j J
keycode 48 = k K
keycode 45 = l L
keycode 54 = m M
keycode 53 = n N
keycode 39 = o O
keycode 43 = p P
keycode 20 = q Q
keycode 23 = r R
keycode 9 = s S
keycode 25 = t T
keycode 40 = u U
keycode 17 = v V
keycode 21 = w W
keycode 15 = x X
keycode 24 = y Y
keycode 14 = z Z
keycode 61 = Escape
keycode 26 = 1 exclam
keycode 27 = 2 at
keycode 28 = 3 numbersign
keycode 29 = 4 dollar
keycode 31 = 5 percent
keycode 30 = 6 asciicircum
keycode 34 = 7 ampersand
keycode 36 = 8 asterisk
keycode 33 = 9 parenleft
keycode 37 = 0 parenright
keycode 35 = minus underscore
keycode 32 = equal plus
keycode 56 = Tab ISO
LeftTab
keycode 41 = bracketleft braceleft
keycode 38 = bracketright braceright
keycode 44 = Return
keycode 70 = Control_L
keycode 49 = semicolon colon
keycode 47 = apostrophe quotedbl
keycode 58 = grave asciitilde
keycode 18 = E E
!keycode 18 = backslash bar
keycode 50 = backslash bar
keycode 51 = comma less
keycode 55 = period greater
keycode 52 = slash question
keycode 59 = BackSpace BackSpace
!keycode 59 = BackSpace Terminate_Server
keycode 62 =
keycode 64 = Shift_L
keycode 68 = Shift_R
keycode 66 = Alt_L Meta_L
keycode 57 = space space
keycode 65 = Caps_Lock
keycode 130 = F1
keycode 128 = F2
keycode 107 = F3
keycode 126 = F4
keycode 104 = F5
keycode 105 = F6
keycode 106 = F7
keycode 108 = F8
keycode 123 = Home
keycode 134 = Up
keycode 131 = Left
keycode 132 = Right
keycode 127 = End
keycode 133 = Down
keycode 125 = Delete
keycode 113 = Print Sys_Req
keycode 124 = Page_Up
keycode 129 = Page_Down
clear Shift
clear Lock
clear Control
clear Mod1
clear Mod2
clear Mod3
clear Mod4
clear Mod5
add Shift = Shift_L Shift_R
add Lock = Caps_Lock
add Control = Control_L
add Mod1 = Alt_L
What does shift-e produece in a remote client?
Does shift-e produce an "E" in a local xterm?
Did you try "xev" command to see the keycode/keysym of shift-e?
What happens if you manually run "xmodmap your
mapfile" ?
[shift-e] as I explained in my original message produces a lowercase letter e. All other keys produce the correct uppercase variant when [shift] is in effect. It doesn't matter if [left-shift] or [right-shift] is used.
I don't know what you mean by "local xterm". If you mean an xterm client compiled and running on the Mac system that is also running the Mac X11 server the answer is no. But all Mac applications, including third-party apps like PhotoShop, Firefox and gvim, produce a capital letter E when [shift-e] is pressed.
The xev(1) command reports keysym 0x65 (lowercase e) whether or not the shift modifier is in effect. For all other keys the proper shifted keysym is reported (e.g., 0x61 for [a] and 0x41 for [shift-a]). There is nothing in the xev output which is different between the correctly behaving keys versus the letter e key.
Running "xmodmap my.xmodmap" before instantiating any other connections to the X11 server, as the last thing before starting the Linux window manager, and manually from an xterm makes no difference.
Note that it isn't just the behavior of the letter e when shifted (which, by the way, produces an uppercase letter E when [caps-lock] is in effect). It is also the keysysms of three numeric keys that is wrong when [caps-lock] is in effect.
The Tiger X11 server works correctly with respect to these specific issues.
I'm happy to collect any diagnostic information people think would be useful including capturing network traces with tcpdump/ethereal/wireshark.
If you mean an xterm client compiled and running on the Mac system that is also running the Mac X11 server
Yes.
I want to make sure that the Linux host is not involved in the prblem. So please do any test in a local xterm, without starting any client (or "window manager"?, do you mean Gnome/KDE?) on the Linux.
The xev(1) command reports keysym 0x65 (lowercase e) whether or not the shift modifier is in effect.
Please check the output of "xmodmap -pke". Are the keysyms for keycode=22 correctly set?
In xev, what is the "state" (= modifier mask) when you hit shift-e, etc.?
The bit masks are 0x01 = Shift, 0x02 = CapsLock.
What is the setting in X11 Preferences>Input>Follow system keyboard layout"? Does changing it have any effect?
If you connect a "standard" keyboard (Apple's one, or any "standard" PC keyboard) to your Mac, does it work normally in X11?
I'm not familiar with Kinesis keyborad, but is it capable of any hardware customization? Can you "reset" it? Does the keyboard require a special driver software?
IMPORTANT: The Tiger and Leopard X11 servers classify my keyboard model as
"generic" and "pc101" respectively. The latter is arguably more correct but
is the configuration that doesn't work.
The Kinesis keyboard is a standard keyboard that does not require any
special drivers. I've used two of them connected to various Linux, Mac, and
Windows systems for several years. The upgrade to Mac OS X Leopard is the
first time I've had a problem with one of these keyboards that I couldn't
solve with xmodmap or the keyboard's native remapping facility. Note that
the keyboard works fine with native Mac OS X Leopard apps. It is only the
keyboard as exported by the Mac OS X Leopard X11 server to other X11 clients
that is problematic.
Note that I'm running the Leopard X11 server in "rootless" mode via
this invocation
The "-rootless" option isn't valid for the Tiger X11 server.
Setting "X11 Preferences" -> "Input" -> "Follow system keyboard layout"
makes the behavior worse. The "xmodmap my.xmodmap" invocation during the
startup of the Linux client is seemingly ignored. Running that command
several seconds later causes unshifted keys to work as expected but the
[shift] modifier has no effect. The "Enable key equivalents under X11"
option has to be selected to get any sort of reasonable behavior (true for
Tiger and Leopard).
When switching from the Tiger X11 server to the Leopard X11 server the
Linux Gnome environment displays the dialog
The X system keyboard settings differ from your
current GNOME keyboard settings.
Expected was model "generic", layout "us" and no options.
but the following settings were found: model "pc101",
layout "us" and no options.
Switching from the Leopard X11 server to the Tiger X11 server causes GNOME
under Linux to complain that the inverse occurred. That is, the keyboard
model changed from "pc101" to "generic".
I clicked the [Use X settings] button. Below is the output of "xmodmap
-pke" from a Linux xterm after running "xmodmap my.xmodmap". Keycode
22 is the letter [e].
Here is the output from xev(1) from the Linux system via Mac OS X Leopard
when pressing and releasing keycode 22 (the letter [e]) without and with the
[shift] key pressed. Notice that the "state" value is correct yet the keysym
is incorrect when state == 1 (i.e., [shift] is in effect).
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755159947, (93,66), root:(149,147),
state 0x0, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755160059, (93,66), root:(149,147),
state 0x0, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755160715, (93,66), root:(149,147),
state 0x0, keycode 68 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755161491, (93,66), root:(149,147),
state 0x1, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755161611, (93,66), root:(149,147),
state 0x1, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 755161715, (93,66), root:(149,147),
state 0x1, keycode 68 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Here is the equivalent xev(1) output from pressing the key for the
letter [a] with and without [shift] under Mac OS X Leopard. All letter
keys other than [e] produce the expected uppercase letter:
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756695801, (139,153), root:(195,234),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756695921, (139,153), root:(195,234),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756696620, (139,153), root:(195,234),
state 0x0, keycode 68 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756697425, (139,153), root:(195,234),
state 0x1, keycode 8 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (41) "A"
XmbLookupString gives 1 bytes: (41) "A"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756697505, (139,153), root:(195,234),
state 0x1, keycode 8 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (41) "A"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1e00001,
root 0x3f, subw 0x0, time 756697681, (139,153), root:(195,234),
state 0x1, keycode 68 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Here is the output from xev(1) from the Linux system via Mac OS X Tiger
when pressing and releasing the letters [a] and [e] without and with the
[shift] key pressed. Notice that [shift-e] produces the correct keysym:
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340452457, (74,109), root:(130,219),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340452614, (74,109), root:(130,219),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340452856, (74,109), root:(130,219),
state 0x0, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340453493, (74,109), root:(130,219),
state 0x1, keycode 8 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (41) "A"
XmbLookupString gives 1 bytes: (41) "A"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340453645, (74,109), root:(130,219),
state 0x1, keycode 8 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (41) "A"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340453786, (74,109), root:(130,219),
state 0x1, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340454575, (74,109), root:(130,219),
state 0x0, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XmbLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340454669, (74,109), root:(130,219),
state 0x0, keycode 22 (keysym 0x65, e), same_screen YES,
XLookupString gives 1 bytes: (65) "e"
XFilterEvent returns: False
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340454778, (74,109), root:(130,219),
state 0x0, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340454973, (74,109), root:(130,219),
state 0x1, keycode 22 (keysym 0x45, E), same_screen YES,
XLookupString gives 1 bytes: (45) "E"
XmbLookupString gives 1 bytes: (45) "E"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340455051, (74,109), root:(130,219),
state 0x1, keycode 22 (keysym 0x45, E), same_screen YES,
XLookupString gives 1 bytes: (45) "E"
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1600001,
root 0x57, subw 0x0, time 340455122, (74,109), root:(130,219),
state 0x1, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Now (finally) I understand your goal is to run a GNOME session remotely, but to see whether the problem is GNOME-related or not, please do any tests in a local xterm without connecting to any Linux hosts. (start X11 by double clicking /Applications/Utilities/X11.app). Also, if you have another keyboard (I guess you have not thrown away the Apple keyborad which came with the Mac Pro), then please test with it to see whether the problem is related with the Kinesis keyborad or not.
Anyway, if "xmodmap -pke" gives "keycode 22 = e E", and "state = 0x01, keycode=22" when you hit shift-e, then I have no idea why it translates into not "E" but "e". Sorry but I hope someone else will come up with better suggestion.