Depuis la version 2.1, XFree86 initialise sa keymap d'après celle de Linux, dans les limites du possible. Linux a 16 entrées par touches (une pour chaque combinaison de Shift, AltGr, Ctrl, Alt; en fait il en a même 256), alors que X n'en a que 4 (une pour chaque combinaison de Shift et Mod), il y a donc forcément des informations perdues.
D'abord X lit le fichier Xconfig, où il trouve les
correspondances entre les touches Control, Alt et ScrollLock avec les
codes X Meta, ModeShift, Compose, ModeLock et ScrollLock - voir
X386keybd(1), ou XFree86kbd(1).
Par défaut, c'est la colonne LeftAlt qui sert pour Mod, sauf si
CtlDroit est défini comme ModeShift ou ModeLock, dans ce cas ce sont
les entrées RightCtl qui servent pour Mod. (Sauf si AltGr est défini
comme Mod dans Xconfig, auquel cas c'est la colonne RightAlt qui sert.)
Ceci détermine comment les 4 entrées de XFree86 sont choisies parmi
les 16 de Linux. Notons que par défaut Linux ne fait pas la différence
entre les deux touche Control ou Shift. X fait la dufférence.
Les touches "action" Show_Memory, Show_State, Show_Registers, Last_Console, Console_n, Scroll_Backward, Scroll_Forward, Caps_On et Boot sont ignorées, de même pour les touches mortes, NumLock, ScrollLock et Alt+code-ASCII.
Ensuite, les définitions de Xconfig sont utilisées. (Donc une
définition de Compose dans Xconfig annulera celle trouvée dans la
keymap du noyau.)
Que deviennent les chaînes associées aux touches des fonctions ? Rien,
ce concept n'existe pas sous X. (Mais il est possible de définir des
chaînes associées aux touches de fonction dans xterm - mais elles
ne doivent pas être interceptées par le gestionnaire de fenêtres.)
Je ne sais pas comment convaincre xterm qu'il devrait utiliser la
keymap de X quand Alt est enfoncé. Il semble qu'il ne réagisse qu'en
fonction de sa ressource eightBitInput, et selon qu'elle est à
vrai ou faux, soit il met à 1 le huitième bit, soit il génère un
caractère escape devant le caractère (comme le fait setmetamode(1)
pour la console).