Le duodi 22 thermidor, an CCXXIII, Thomas Schmitt a écrit : > Still trying to grok the xkb stuff, i get the impression > that at least on my system xterm gets to see Alt+Space, not a > "nobreakspace" produced by general keyboard translations.
I suppose everybody already knows this, but to check what keys applications receive from the X11 server, the xev program can be of great help. Less known fact: to get the current full XKB mapping of the server, the following command does the trick: xkbcomp $DISPLAY - (you can usually type ":0" instead of $DISPLAY of course) The xkb_keycodes section is just a set of symbolic constant names for hardware keycodes, plus for some reason the label for the keboard LEDs. The xkb_types section defines types of keys, depending on the effect of alt, shift, ctrl, etc., keys. Writing a new type is not straightforward, but the existing types are usually rather self-explanatory. The xkb_compatibility section defines the effect of special keys. The xkb_symbols section defines the actual symbols attached to each key. And lastly, the xkb_geometry defines the physical layout of the keyboard, in case you want to display it. For a few more details, you can have a look at my personal notes: http://nsup.org/~george/articles/personal_xkb_notes.html > But i may be wrong. Still did not find a comprehensive > introduction to the model of keyboard processing in X. This is not comprehensive, but this is a start: Applications get KeyPress (and KeyRelease) events, with, amongst other things a keycode corresponding to the hardware code of the key, and a state that encodes the currently active modifiers (shift, num-lock, etc.). Bogus applications stop there. Correct applications then must call the Xlib (or another library performing the same task) to translate the keycode and state into a "keysym" (key symbol) or a string. Keysyms are for direct key handling: movement, keyboard shortcuts, etc. For text entry, the string must be used, otherwise input methods (even simple compose and dead keys) do not work. Then, some toolkits will add their own translation mechanism. XTerm uses the "X Toolkit Intrinsics", aka "Xt". Xt has a per-widget translation mechanism mapping expanded X11 events to high-level functions. Documentation can be found in the libxt-doc package. And lastly, applications can do their own mangling of the resulting keys or text. XTerm does, it encodes the Meta/Alt modifier for applications by either prefixing each character key with the Esc code or by adding 128 to the ASCII code of characters, based on the metaSendsEscape, altSendsEscape resource and a few others. Untangling the interaction of the +128 option with UTF-8 environments is left as an exercise to the reader. If everything was not already complicated enough, shift, control and caps-lock have each a fixed value in the state mask, but all the other modifiers (from num-lock to alt-gr, including meta and super) arrive to the application as mod1 to mod5, with an arbitrary mapping. Applications (or toolkits) that want to allow alt- or meta-prefixed shortcuts are supposed to inspect the key mapping table to identify the correct modX. They usually get it wrong, frequently hard-coding mod1 = alt (to react to it) and mod2 = num-lock (to ignore it). Next The Onion headline: a disgruntled Debian user opens fire at a X.org developers meeting before committing suicide by eating the full set of X11 reference manuals. (Although to be fair, the current X.org developers are probably suffering from that old design as much as anybody else.) Regards, -- Nicolas George
signature.asc
Description: Digital signature
