Je donne ici quelques informations sur XKB (X keyboard extension), en particulier pour modifier la configuration en tant que simple utilisateur (sans accès root). Ainsi ma configuration XKB a complètement remplacé mon ancien fichier .xmodmaprc (qui ne fonctionnait pas correctement avec le nouveau driver kbd).
Deux commandes utiles:
Pour afficher les paramètres actuels: setxkbmap -print
Pour écrire la description XKB du clavier dans un fichier xkb.dump: xkbcomp $DISPLAY xkb.dump
Dans son $HOME
, créer un répertoire .xkb et 2 ou 3 sous-répertoires:
keymap: ce répertoire contiendra un fichier avec les paramètres du clavier. Il pourra être basé sur la sortie de setxkbmap -print.
symbols: ce répertoire contiendra un fichier avec les touches remappées. Des exemples peuvent être trouvés grâce à xkbcomp $DISPLAY xkb.dump (voir la section xkb_symbols) ou aux fichiers du répertoire /usr/share/X11/xkb/symbols (voir par exemple les fichiers latin et pc).
Exemple: mon fichier ~/.xkb/symbols/local.
types (optionnel): ce répertoire peut contenir un fichier avec de nouveaux types de touches, si besoin est.
Exemple: mon fichier ~/.xkb/types/local.
Pour utiliser ces paramètres locaux, j'ai les lignes suivantes dans mon script ~/.xsession:
if [ -d $HOME/.xkb/keymap ]; then setxkbmap -types local -print | \ sed -e '/xkb_symbols/s/"[[:space:]]/+local&/' > $HOME/.xkb/keymap/custom xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY fi
Ceci crée un fichier ~/.xkb/keymap/custom ressemblant à:
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "local" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+gb+inet(evdev)+level3(ralt_switch)+local" }; xkb_geometry { include "pc(pc105)" }; };
(certaines parties peuvent changer, suivant le clavier, sauf les local) et sélectionne ces paramètres quand la session X de l'utilisateur est démarrée.
Références:
Note: Il s'agit ici juste de la configuration du clavier. La configuration du jeu de caractères (encodage) est un autre sujet et dépend des locales. Vous pouvez vérifier ce que vous obtenez avec l'utilitaire xev; regarder la ligne XLookupString.
J'étais assez surpris de voir que dans la configuration par défaut, un modifieur pouvait modifier un autre modifieur:
key <RALT> { type= "TWO_LEVEL", symbols[Group1]= [ ISO_Level3_Shift, Multi_key ] };
si bien que Shift+AltGr donnait Multi_key tandis que AltGr+Shift donnait Shift+LevelThree.
Malheureusement, surtout pour les utilisateurs de portable, les paramètres XKB sont perdus après une mise en veille (c'était déjà le cas avec xmodmap). On peut contourner ce problème: il suffit de les sauver et de les restaurer via pm-utils avec un script dans le répertoire /etc/pm/sleep.d, comme mon script xkb-save-restore, stocké sous la forme /etc/pm/sleep.d/40xkb-save-restore par exemple. Vous devriez aussi avoir besoin d'exécuter
xhost +si:localuser:root
dans votre ~/.xsession puisque le script est exécuté par root à la mise en veille et à la reprise, et l'environnement de root n'a pas les informations xauth (MIT-MAGIC-COOKIE-1) de l'utilisateur, qui lui permettraient d'avoir accès à la configuration du clavier sans autorisation spéciale.
Note: L'inconvénient (ou l'avantage) de la commande ci-dessus est que root peut avoir un accès permanent à la session graphique (display) de l'utilisateur. Ceci n'est pas réellement un problème lié à la sécurité puisque root contrôle tout sur la machine, et en particulier, peut avoir accès au magic cookie par divers moyens. Mais l'utilisateur doit faire attention à ne pas lancer par erreur certaines applications X sous root.
Le seul véritable problème est que lorsque les paramètres doivent être restaurés, bien que xkbcomp termine sans erreur, il n'a parfois aucun effet.
Sur certains claviers, les touches sont mal placées et par exemple, on peut vouloir en échanger. XKB ne doit pas être utilisé pour cela, car l'effet serait appliqué à chaque clavier. Il est nécessaire de modifier le keymap au niveau du pilote via udev.
Par exemple, pour mon clavier USB Apple Aluminum (que j'utilise avec mon portable, si bien qu'il s'agit d'un deuxième clavier), j'ai utilisé les solutions suivantes, suivant la version de udev.
Note: Le scancode d'une touche physique peut être obtenu avec l'utilitaire evtest. Il suffit de taper sur la touche et de regarder une ligne comme:
Event: time 1452726874.519482, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70068
Le scancode est ici 70068 (c'est une valeur hexadécimale).
J'avais les deux fichiers suivants:
0x70035 86 # Left to z: 102nd (providing backslash bar) 0x70064 grave # Left to 1: grave notsign 0x70068 insert # F13
ACTION!="remove", SUBSYSTEMS=="usb", ENV{ID_VENDOR_ID}=="05ac", ENV{ID_MODEL_ID}=="0221", RUN+="keymap $name /etc/udev/keymaps/apple-aluminum"
Note: à cause d'un bug dans l'utilitaire keymap de udev, j'ai dû donner le code 86 de la touche au lieu de son nom 102nd (le fait que ce dernier commence par un chiffre perturbe l'utilitaire keymap).
À partir de la version 208, l'utilitaire keymap de udev n'existe plus. Il y a un nouveau système de remapping, plus simple. Cf le fichier /lib/udev/hwdb.d/60-keyboard.hwdb pour la documentation et des exemples. J'ai initialement eu des problèmes à cause de multiples erreurs de documentation, maintenant corrigées (et les utilitaires ne signalaient pas les erreurs).
J'avais le fichier /etc/udev/hwdb.d/98-apple-keyboard.hwdb suivant:
keyboard:usb:v05ACp0221* KEYBOARD_KEY_70035=102nd # Left to z: backslash bar KEYBOARD_KEY_70064=grave # Left to 1: grave notsign KEYBOARD_KEY_70068=insert # F13: Insert
Attention! Chaque ligne de mapping de touche doit commencer par une seule espace. Les erreurs ne sont pas signalées!
Après la création ou la modification de ce fichier, il faut mettre à jour la base de données correspondante avec: udevadm hwdb --update
On doit ensuite exécuter udevadm trigger, ou simplement redémarrer (ce qui est probablement plus propre).
Le préfixe a changé. Le nouveau fichier /etc/udev/hwdb.d/98-apple-keyboard.hwdb est:
evdev:input:b0003v05ACp0221* KEYBOARD_KEY_70035=102nd # Left to z: backslash bar KEYBOARD_KEY_70064=grave # Left to 1: grave notsign KEYBOARD_KEY_70068=insert # F13: Insert
Attention! Chaque ligne de mapping de touche doit commencer par au moins une espace (une seule pour compatibilité avec les anciennes versions d'udev).
Après la création ou la modification de ce fichier, il faut mettre à jour la base de données correspondante avec: udevadm hwdb --update
On doit ensuite exécuter udevadm trigger /dev/input/eventXX sur le bon fichier d'événement, ou simplement redémarrer (ce qui est probablement plus propre).
Note: Certains choix de mapping peuvent être parfois contrôlés par des options du pilote. C'est le cas ici avec ce clavier Apple particulier pour les deux premières lignes KEYBOARD_KEY_. Mais de toute façon, j'ai toujours besoin d'un tel fichier pour avoir une touche Insert.
La catégorie Keyboards du wiki d'Arch Linux a des informations intéressantes.