Il y a deux couches ici, le mappage KEYCODE vers KEYSYM et le mappage KEYSYM vers le texte. Il y a plus de couches si vous comptez le noyau, qui doit mapper les scancodes du clavier AT à un KEYCODE de style XT ou un code HID de clavier USB à un KEYCODE. Un KEYCODE est simplement un entier non signé 8 bits que le noyau d'un système d'exploitation transmet au serveur X11. Il peut varier entre les systèmes d'exploitation tels que Linux et Solaris. Sous Linux, ces KEYCODE sont généralement les mêmes que ceux utilisés sur les anciens claviers XT PC. Les nouveaux ordinateurs équipés de claviers AT, PS / 2 ou USB mappent généralement ces claviers à l'ancien code XT pour que la clé reste simple.
Les codes de clavier bruts, qu'ils soient XT, AT, PS / 2 ou USB, représentent un emplacement physique sur un clavier. Le clavier XT envoie uniquement un seul numéro de 8 bits lorsque vous appuyez ou relâchez une touche. La touche q sur un clavier US / British XT envoie le nombre 16. Sur un clavier français, cette même touche physique est étiquetée a, mais elle envoie toujours 16. Ce sont les couches supérieures du système d'exploitation qui lui attribuent une signification réelle. Lorsqu'une touche est relâchée sur un clavier XT, le même code de touche est envoyé plus 128. Pour cet exemple, lorsque q est enfoncé, un 16 est envoyé, mais au relâchement, le nombre 142 (16 + 128) est envoyé. Les claviers AT utilisent des scancodes qui sont une série de nombres et peuvent être assez longs. Les versions clés ajoutent des codes supplémentaires. Par exemple, le scancode de la pause est E1, 1D, 45, E1, 9D, C5. La plupart des systèmes d'exploitation, y compris DOS, Windows, Linux, FreeBSD, et le BIOS mappe tous les scancodes en scancodes beaucoup plus simples de style XT. Il permet également de prendre en charge plus facilement les claviers plus récents qui utilisent différents codes tels que les claviers USB qui envoient des codes HID. Tous les codes sont mappés sur le même ensemble cohérent de codes par le système d'exploitation avant que X11 ou l'application ne les voit.
X11 ignore cette partie du processus, il obtient simplement le KEYCODE du noyau et applique son propre mappage pour convertir ce KEYCODE en KEYSYM. Xmodmap est l'outil standard pour contrôler ce mappage. Une grande partie du comportement du mappage du clavier est configurable, mais il existe plusieurs cas spéciaux tels que le verrouillage numérique, le commutateur de mode et le verrouillage des majuscules / verrouillage des majuscules qui sont codés en dur dans X11. D'autres aspects comme Shift sont réellement configurables. N'importe quelle touche peut être mappée pour agir comme décalage, contrairement au commutateur de mode ou au verrouillage numérique.
Les KEYCODE représentent les clés physiques envoyées par le noyau du système d'exploitation. Chaque KEYCODE peut correspondre à 8 KEYSYM possibles. Seuls 4 sont utilisés et sont parfois appelés niveaux 1-4. Le niveau 1 spécifie le KEYSYM qui est imprimé lorsqu'aucun modificateur n'est actif. Ce sont souvent des lettres et des chiffres en minuscules. Les modificateurs sont des KEYCODE qui modifient le KEYSYM généré par d'autres KEYCODE lorsque le modificateur est actif (enfoncé ou activé). Les codes-clés des modificateurs sont également contrôlés via Xmodmap. Le niveau 2 spécifie un KEYSYM à envoyer lorsque vous appuyez sur le modificateur de décalage. Le niveau 3 est activé chaque fois que le commutateur de mode KEYSYM a été enfoncé. Le niveau 4 est activé lorsqu'une touche Maj et un commutateur de mode sont actifs.
Une fois qu'un KEYSYM a été généré, il peut être interprété directement, mais le plus souvent il sera converti en texte. Tous les KEYSYM ne se transforment pas en texte ou ne peuvent affecter qu'un futur KEYSYM. Un exemple est Shift_L, bien sûr, qui n'a pas de représentation textuelle, mais il existe également un certain nombre de KEYSYM qui sont utilisés pour composer un autre caractère. Une liste d'entre eux sur mon système est en dessous /usr/share/X11/locale/en_US.UTF-8/Compose. Un tel exemple est le KEYYM dead_acute qui, une fois pressé, tentera de convertir le KEYSYM suivant en une lettre accentuée aiguë. Il existe un mappage standard pour transformer les KEYSYM en Unicode.
Maintenant que tout cela a été dit, notez que Xmodmap est obsolète et remplacé par XKB qui est beaucoup plus sophistiqué. Cela affecte la façon dont les KEYCODE sont mappés aux KEYSYM, mais pas la façon dont le noyau génère les KEYCODE ni la façon dont les KEYSYM sont convertis en texte ou composés, ce qui est toujours le même. XKB peut être désactivé pour restaurer le comportement de Xmodmap. Il a également une couche de compatibilité pour prendre en charge Xmodmap, mais il peut avoir des problèmes car il n'est pas complètement compatible. Les règles XKB sont en dessous /usr/share/X11/xkb/et sont beaucoup plus sophistiquées. Il existe une bonne documentation ailleurs sur la façon dont il génère des dispositions de clavier pour mapper des KEYCODE à KEYSYM.
Quant à la console Linux, elle a ses propres dispositions de clavier qui sont stockées /usr/share/keymapset chargées avec la loadkeyscommande. Dans le BIOS et les étapes précédentes du chargeur de démarrage, y compris GRUB2, le mappage du clavier est le nombre auquel le BIOS décide de mapper la clé.