On Debian Linux 3.1 with Gnome I have problems with
shifted function keys not generating the correct bindings.
% puts $tcl_patchLevel
8.4.12
% puts $tk_patchLevel
8.4.12
% bind . <Any-Key> {puts %K}
I then hit shift F1 and it prints up:
Shift_L
XF86_Switch_VT_1
Gnome uses xkb and it has definitions as follows:
$ less /etc/X11/xkb/symbols/pc/pc
...
// Begin "Function" section
key <FK01> {
type="CTRL+ALT",
symbols[Group1]= [ F1, XF86_Switch_VT_1 ]
};
...
This *should* mean control+alt+F1. Indeed pressing that
switches to the first text console.
I can override this using xmodmap, which on my keyboard
layout means:
keycode 67 = F1
...
If I use xmodmap on that then Tcl correctly reports
Shift_L and F1 for shift+F1 and bindings work as
expected. However I then cannot do control+alt+f1 to
switch to text console 1.
This implies two things.
1) xkb is working and Control + Alt really are the
modifiers for F1 to switch consoles. (Shift F1 wasn't
switching consoles)
2) Tk is confusing the Control+Alt as a Shift modifier.
I think this has been a stealth change in XFree86. Xkb
is hopelessly poorly documented. Using "xmodmap -pke |
grep F1" also shows XF86_Switch_VT_1, but the confusion
lies in the assumption that the second keysym value
means Shift. My understanding is that previously the
second level was always shift and functions like
XLookupKeysym assume this, but once xkb was added the
second level could be mapped to another modifier
(Ctrl+Alt in this case). Supposedly XLookupString is
xkb aware but XLookupKeysym is not. IMO this is an X
bug (or at least an undocumented X incompatibility),
but not according to the xkb developers so it would seem.
Searching around I did find suitable hints elsewhere -
XEmacs had the same bug but they've now fixed it. The
following 2 URLs may help:
http://bugs.xfree86.org/show_bug.cgi?id=643
http://list-archive.xemacs.org/xemacs-beta/200309/msg00044.html
It sounds like XEmacs solved the issue by using
XLookupString instead, but that appears to be what Tk
uses anyway.
James
