Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Hi, 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 They are 'old layouts'. % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work They are new ones. These are the settings I normally use, Scroll_Lock is of no use for me under X, but this maybe be a problem. The thing is new layouts have three-four levels and need a modifier bit for switching to those levels. But all real modifiers are already used: Lock, Shift, Control - according their names, and unnamed ones (Mod1-Mod5) are Alt, Meta, NumLock, ScrollLock and one for a Mode_Switch emulation for compatibility with the core protocol. Thus for the new ThirdLevel modifier I had to sacrifice one of them. The ScrollLock modifier seems me most unused and now this bit is used as the ThirdLevel modifier (of course the ScrollLock key still prodice a corresponded keysym). But the ScrollLock indicator still configured to show state of modifier bound to the ScrollLock keysym. I think if complaints will come I'll make an option that maps the ScrollLock virtual modifier to some real one. Otherwise we can use the indicator for something else. -- 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
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works They are 'old layouts'. % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work They are new ones. The thing is new layouts have three-four levels and need a modifier bit for switching to those levels. But all real modifiers are already used: Lock, Shift, Control - according their names, and unnamed ones (Mod1-Mod5) are Alt, Meta, NumLock, ScrollLock and one for a Mode_Switch emulation for compatibility with the core protocol. Thus for the new ThirdLevel modifier I had to sacrifice one of them. The ScrollLock modifier seems me most unused and now this bit is used as the ThirdLevel modifier (of course the ScrollLock key still prodice a corresponded keysym). But the ScrollLock indicator still configured to show state of modifier bound to the ScrollLock keysym. I think if complaints will come I'll make an option that maps the ScrollLock virtual modifier to some real one. Otherwise we can use the indicator for something else. I think there won't be too many complaints about the ScrollLock leds not working. I am just not sure if there aren't programs that rely on ScrollLock working as before. For safety, I believe a xkb option for that case would be a good idea. BTW, I just tested the changes for MouseKeys, it is now working properly, thanks Ivan. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
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]
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click Both problems are side-effects of an adding 'special key sequences' such as Ctrl+Alt+Keypad +, Ctrl+Alt+Keypad -, etc. (You see only keys that have a special action are affected.) Tommorow I will write an explaination and will try to offer a workaround for both problems. -- 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
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: 'xset r keycode' works. I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click Both problems are side-effects of an adding 'special key sequences' such as Ctrl+Alt+Keypad +, Ctrl+Alt+Keypad -, etc. (You see only keys that have a special action are affected.) Tommorow I will write an explaination and will try to offer a workaround for both problems. Thanks. My understanding of xkb isn't very good, but, could the new special key sequences be implemented as MouseKeys, i.e. as the descriptions in xkb/compat? (but always enabled). -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
