Quoting Ivan Pascal <[EMAIL PROTECTED]>: > 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?
Thanks for the explanation Ivan. I think creating a compatibility map seens the more sensate solution. I am just not sure what is the more robust/easy to maintain/predictable solution, but my instincts says it is the second option :-) Err, I think is just found another problem, forgive me if it is a known problem (and I missed some email about it), but for example: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br => Scroll_Lock leds works % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt => Scroll_Lock leds dont work These are the settings I normally use, Scroll_Lock is of no use for me under X, but this maybe be a problem. > -- > 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 Paulo _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
