Welcome to the XKB modifiers nightmare.Thanks for the warm welcome ;)
The thing is, a core protocol binds modifiers to keys (not to keysyms) butI determined that GTK+ 2 has its own keyboard processing code (it does grab the keys, as you suggested, in file gdkkeys-x11.c I believe), so I won't care about it at the moment.
XKB has own 'virtual' modifiers (which it can change by 'XKB actions') and
needs to map them to the core protocol's 'real' ones. This mapping could be
done simply writing pairs virt_modifier<->real_modifier somewhere in XKB
configuration files.
But since an application can try to change a modifier_to_key binding
using the core protocol, XKB has to support a backward compatibility and do
it in an intricate way.
But, if I put "Control" as level five modifier (remove modifier_map Mod4 in the "sr" file, and replace every occurence of "Mod4" with "Control" in file "sixlevel"), xterm doesn't recognize sequences correctly.
The problem is that in XkbTranslateKeySym (around line 730), mods=0, even though the "Control" is pressed and is state is reported in xev as 0x4 later, the (mods&ControlMask) evaluates to 0, and XkbToControl is bypassed. Because of this, xterm receives 'c' in XLookupString buffer instead of ('c'&0x1f). The same is with other apps, but they don't seem to care, or maybe do something like XkbToControl themselves.
I've noticed some new_mods manipulations in XKBBind.c, and when I replaced the line (around 770 in XLookupString)
new_mods= (event->state&(~new_mods));
with line
new_mods=event->state;
xterm seemed to work correctly (and other apps worked too, I couldn't detect any error except for Gtk+ which was not effected). But, I don't know what have I actually broke this way (probably I have something). For the record, the state on those lines was new_mods=0x87 and event->state=4, so the resultant new_mods was always 0 in the previous scenario (pressing CTRL+C with loaded my sixlevel-serbian-cyrillic map at first group).
Also, I was able to make xterm work without such change, if I add similar checks and conversions to it (in file xc/programs/xterm/input.c).
Yes, now I see. I didn't quite bother interpreting the state, but now with xkbwatch and your guidance, I believe to understand it.KeyPress event, serial 25, synthetic NO, window 0x3200001,
root 0x40, subw 0x0, time 12563178, (400,268), root:(403,344),
state 0x44, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: ""
Dont't you guess 'state 0x44' means two bits (real modifiers) are set
together? They are Mod4 and Control.
My mistake was that I assumed that "modifier_map" actually overrides any other setting, not merges with it.
As noted above, you're correct.This is how programs act with Control as level five modifier:
- GTK+ 2 (gedit, Galeon,... ) simply pressing a key acts as if Control+key is pressed (so, typing a cyrillic "a" tends to select my entire text, instead of outputing "__").
Maybe it uses a key grabing. In this case an application just request
a notification when some key (keycode) is pressed and the current state of
modifiers match the modifiers specified in the grab request.
It seems to me that appropriate would be to have state 0x44 and XLookupString to receive "d" when CTRL+D is pressed. How can I achieve that?
Maybe I need to modify "interpret" sequences in "compat"?
Maybe.
And do you know that xkbcomp can make a 'snapshot' of the current keyboard
map where you could see what mappings you got?
Yes, I already used it to check for syntax errors, as in: setxkbmap sr -print | xkbcomp -xkb -o mojamapa.xkb -
Thanks for all the help!
Cheers, Danilo
_______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
