Hi,
A short introduction:
Any key in XKB can have keysyms, xkb actions, a virtual modifier(s) and some
flags describing a key behavior such as 'repeat', 'locking' and so on.
A core protocol knows about keysyms only. If one changes a keysym binding
using the core protocol it can happen that the keysyms only will be moved but
not actions or behavior flags.
To solve this compatibility problem the XKB has a special 'compatibility map'
which sets a relation between keysyms and other attributes a key can have.
Thus when some keysym place in the keyboard map is changed the XKB searches
this keysym in the compatibility map and if the keysym is found there it also
moves an action and flags to the key. The same procedure the XKB does after
any keyboard map loading (even it made by an XKB protocol). Therefore although
an action of key can be specified in the symbols map directly it is a common
way to tie the action to some special keysym in the compatibility map
(xkb/compat/* files) and specify that keysym in the symbols map.
Also each key has 'protection flags' which can protect the key from such
changes. These flags are
- 'forbid all changes' (include an action, a virtual modifier and other flags)
- 'forbid a repeat flag change'
- 'forbid a lock flag change'
- 'forbid a modifier change'
All written above you can read in XKBproto or XKBlib documentation. But you
can't find there when and how those protection flags are set.
The xkbcomp program does it using rules:
- if any action for some key is specified directly in the symbols file the
'forbid all changes' flag should be set for this key
- if a repeat flag is specified there the 'forbid a repeat flag change' bit
should be set.
- and similar rules for a locking flag and a virtual modifier.
Now you can guess what happened with 'mouse actions'. Since new special
actions were specified directly in the symbols map the xkbcomp set the
protection flags for the corresponded keys and the 'mouse actions' which are
tied to keysyms in the compatibility map now can't be bound to those keys.
A disappearing of autorepeat isn't so clear but caused by the same reason.
There are some details in an XKB design (I consider them as bugs) which lead
to it. All keys initialy have not an autorepeat mark unless it explicitly
specified in the symbols map (you know there are not such explicit
spcifications in existent maps). The XKB sets these marks (bits) after a new
map loading but does it for each key separately after attempt to apply
a compatibility map ( of course if the key has not any keysyms mentioned in
that map the autorepeat mark will be set unconditionaly).
Thus if the key has the protection flag the XKB interrapts compatibility
map applaying for this key and 'forgets' to set autorepeat but to the key.
Thus you see the autorepeat losing is rather a bug and can be fixed (we need
to make all keys marked as repeating initialy or to place the procedure which
sets those marks before the protection bits checking). But disappearing
of the 'mouse actions' is a feature of the XKB and can't be avoided without
some redesign of XKB.
Therefore a solution for the second problem is to 'make all actions equal
in their rights'. It means
- specify the mouse actions (and the repeat flag) in the same place where the
'special actions' are (e.g. in the symbols map)
- or move the special action to the compatibility map.
In the second case we need to introduce some new keysyms (something like
xf86_Next_VMode, xf86_Prev_Mode, xf86_Ungrab, etc.). But we even don't need
to add them to the keysymdef.h file but can use the lib/X11/XKeysymDB file
instead.
I have tested both solutions and it works in both cases. And I can make
a patch quickly. But we have to chose one.
As for me I prefer the second one becouse it is the way used for all other
xkb actions.
Any suggestions?
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
