Hi,
> For the time being, at least some of Ctrl/Alt dance can be achieved
> using higher levels, so here are my problems.
>
> In the currently designed "sixlevel" type (one at
> http://www.kvota.net/srpski/1.5/sixlevel), where <LCTL> is
> modifier_map-ed to Mod4, it works as expected (it does select level
> five) in GTK+ 2.x apps and in Xterm. But, Emacs 21.3.50.2 (it's same
> with the "old" Emacs 21.2.1) shows with describe-key that it reads it as
> if C-s-x (CTRL+S+X, not CTRL+Shift+X) is pressed when I press only C-x.
> KDE apps (KWrite) don't work at all.
Welcome to the XKB modifiers nightmare.
The thing is, a core protocol binds modifiers to keys (not to keysyms) but
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.
The modifier_map instruction ties a real modifier to some key (key can be
specified as a key name or as a name of the keysym tied to this key).
Also each key can have a virtual modifier. If a key has both the real
modifier and the virtual one, XKB makes a pair virtual_to_real and uses it
as a mapping.
But all virtual_modifier_to_key bindings are hidden in the 'compat' files
(where the modifiers are bound to special keysyms) or even hidden somewhere
in xkbcomp's defaults.
On the other hand applications that don't know about XKB virtual modifiers
need to recognize what each of the unnamed real modifers (Mod1-Mod5) should do.
They also use an indirect way - if a key has any core protocol's modifier
the application gets a keysym(s) from the key and guesses about the modifier
meaning using the keysym name. E.g. if Mod4 modifier tied to the key with
Super_L keysym the applications supposes the Mod4 means the Super modifier.
What did you do. You left Mod4-Super and Control_modifier-Ctrl_key mapping
in pc/pc file and added Mod4-Ctrl mapping in your file. Thus XKB thinks
Control_L keysym has to set both the Mod4 and Control real modifiers. But
applications thinks you are pressing two keys - Ctrl and Super.
> 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.
> 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.
BTW, do you know about xkbwatch utility? It shows current state of modifiers.
Unfortunately there is not any documentation for it. Its rows mean: base,
latched, locked, effective and real modifiers. And columns are (from left
to right): Mod5, Mod4, ... Mod1, Control, Lock, Shift.
And do you know that xkbcomp can make a 'snapshot' of the current keyboard
map where you could see what mappings you got?
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
