On 12/27/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
It appears that this is already partially fixed by the toolkits, most notably GTK.
As Havoc Pennington already noted in the Mozilla bug 69230, Gtk has special code to handle it in the GtkKeyHash class: http://cvs.gnome.org/lxr/source/gtk+/gtk/gtkkeyhash.c xev surprises me. Perhaps it was never updated for xkv and uses the old
API?
xev shows you the events as they are. This is what it should do. This only goes to show you that GTK (and others) have a special layer of logic to handle this, i.e. this is not solved on the X11 level by toggling some X11 feature.
I also would like to solve this at the X level.
I think you could create a new XKB "il" mapping where holding Ctrl or Alt is a modifier that activates the 1st shift group. It shouldn't be too hard. It's funny how I never got to it. Ideally, X would provide both the physical key and translated key and
the application would choose according to context.
X keyboard event structs are not going to change any time soon. X11 does not provide you a standardized physical key (unlike, say, WM_KEYDOWN with its VKs): it gives you either the keycode as it's received from the underlying input driver (non-standardized) or the keysym (the key after going thru the full XKB pipeline). The keycodes are tied to your keyboard driver ("keyboard", "evdev"...) and keyboard model (that's why you specify "microsoft104" etc. in your XKB config), so you shouldn't be tempted to use them. There's another kind of code, "key names"; the XKB keyboard model does the key code -> key name translation. Key names are universal but are not supplied in the X11 key event structs :( I have already researched into it during my rdesktop keyboard handling work. In rdesktop, we need to map whatever we receive from X11 into Windows VKs (which are MS defines covering the AT2 standard keyboard). If you wish to resolve a key without the XKB translation layer, you can: 1. Be like VMWare; require root, hook up to the physical keyboard (switch console into raw mode / use evdev). The Linux console guarantees standard AT2 scancodes and performs the necessary translations. 2. Force resolving the key in the Nth group, regardless of the current keyboard group (= language): /* Change the bits (bit 13 to 16 -- see XkbGroupForCoreState) denoting the group. This way, we avoid using XkbKeycodeToKeysym which requires emulation Xkb shift level logics. */ keyevent->state &= ~(0x3 << 13); keyevent->state |= (g_force_xkb_group & 0x3) << 13; XLookupString(keyevent, str, sizeof(str), &keysym, NULL); 3. Programatically request the XKB layout from the X server to get the keycode->keyname (<AAAA>) mapping. (e.g. Run "xkbcomp :0 -" to see what I'm talking about). In any case, physical keys is not something you want *in this case*. Think of Dvorak keyboard layouts.