Hi,
> 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.
It is exactly what the 'preserv' instruction is purposed for.
> 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));
'New_mods' (in the right side) is not a good name for the variable becouse
it doesn't reflect its meaning. Actully it is a bunch of modifiers that
are used in XkbTranslateKeycode for a keysym selection and should not be
considered in the next processing. XkbTranslateKeycode puts there modifiers
mentioned in the 'title' of the type definition
type "SIX_LEVEL_ALPHABETIC" {
modifiers = Shift+Lock+LevelThree+Control;
....
Thus its real meaning is "modifiers that should be removed from event's
state"
But if you know that some modifiers are needed at the next step
(XkbTranslateKeySym) you can specify it explicitly using the preserv
instruction. E.g.
preserve[Control]=Control;
preserve[Shift+Control]=Control;
...
mean the Control modifier should be excluded from the mods_should_be_removed
if the corresponded 'map' instruction was applied.
> 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).
This behavior (removing used mods) can be switched of by the environment
variable _XKB_CONSUME_LOOKUP_MODS.
By default it is 'on'. Such inital value allow to change, for example,
a behavior of the Lock modifier (see types/caps file). If this mode is
switched off the preserv instructions don't work at all but otherwise
we can easy change the beahvior replacing a type definition with/without
the preserv instruction.
> For the record, the state on those lines was new_mods=0x87 and
Yes it is exactly the mask composed from Shift+Lock+LevelThree+Control.
> 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).
:-)
I remember you wrote that the preserv doesn't work. I think you mixed
the problem with Mod4 and with the preserv instriction. Of course, I have
tested it with your files before the writing this message. It works.
--
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
