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.
