Oui, c'est possible avec XKB. Contrairement à xmodmap, XKB peut remapper vos clés pour des appareils individuels.
Remarque :Assurez-vous d'avoir xkbcomp> 1.2.0
Listez d'abord vos appareils avec :
xinput list
Vous obtiendrez quelque chose comme ceci :
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom Bamboo Pen Pen stylus id=11 [slave pointer (2)]
⎜ ↳ Wacom Bamboo Pen Finger touch id=12 [slave pointer (2)]
⎜ ↳ Logitech USB-PS/2 Optical Mouse id=13 [slave pointer (2)]
⎜ ↳ Wacom Bamboo Pen Pen eraser id=14 [slave pointer (2)]
⎜ ↳ Wacom Bamboo Pen Finger pad id=15 [slave pointer (2)]
⎜ ↳ GASIA USB KB V11 id=17 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ G19 Gaming Keyboard id=8 [slave keyboard (3)]
↳ G19 Gaming Keyboard id=9 [slave keyboard (3)]
↳ Logitech G19 Gaming Keyboard id=10 [slave keyboard (3)]
↳ GASIA USB KB V11 id=16 [slave keyboard (3)]
Identifiez la chaîne de votre appareil et modifiez le script shell suivant, en remplaçant la ligne sed par une ligne correspondant au nom de votre appareil. Modifiez ensuite les clés dont vous avez besoin de remapper.
Exemple :Charger xev et appuyez sur une touche que vous souhaitez remapper. Supposons que vous découvriez que c'est le code clé 84. Recherchez 84 dans https://gist.github.com/zoqaeski/3880640. Le nom de la clé est <KP5> . Recherchez ensuite la clé par laquelle vous souhaitez la remplacer (dans le même lien, plus bas) et copiez ce qui se trouve entre les crochets. Répétez le processus pour toutes les clés souhaitées.
remote_id=$(
xinput list |
sed -n 's/.*GASIA.*id=\([0-9]*\).*keyboard.*/\1/p'
)
[ "$remote_id" ] || exit
# remap the following keys, only for my custom vintage atari joystick connected
# through an old USB keyboard:
#
# keypad 5 -> keypad 6
# . -> keypad 2
# [ -> keypad 8
# left shift -> left control
mkdir -p /tmp/xkb/symbols
# This is a name for the file, it could be anything you
# want. For us, we'll name it "custom". This is important
# later.
#
# The KP_* come from /usr/include/X11/keysymdef.h
# Also note the name, "remote" is there in the stanza
# definition.
cat >/tmp/xkb/symbols/custom <<\EOF
xkb_symbols "remote" {
key <KP5> { [ KP_Right, KP_6, U2192, U21D2 ] };
key <I129> { [ KP_Down, KP_2, U2193, U21D3 ] };
key <AD12> { [ KP_Up, KP_8, U2191, U21D1 ] };
key <LFSH> { [ Control_L ] };
};
EOF
# (1) We list our current definition
# (2) Modify it to have a keyboard mapping using the name
# we used above, in this case it's the "remote" definition
# described in the file named "custom" which we specify in
# this world as "custom(remote)".
# (3) Now we take that as input back into our definition of the
# keyboard. This includes the file we just made, read in last,
# so as to override any prior definitions. Importantly we
# need to include the directory of the place we placed the file
# to be considered when reading things in.
#
# Also notice that we aren't including exactly the
# directory we specified above. In this case, it will be looking
# for a directory structure similar to /usr/share/X11/xkb
#
# What we provided was a "symbols" file. That's why above we put
# the file into a "symbols" directory, which is not being included
# below.
setxkbmap -device $remote_id -print \
| sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' \
| xkbcomp -I/tmp/xkb -i $remote_id -synch - $DISPLAY 2>/dev/null
Ensuite, sourcez-le (vous pouvez l'ajouter à votre .xinitrc). Terminé! Appuyez maintenant sur les touches pour générer la sortie souhaitée, uniquement pour l'appareil que vous avez spécifié.
Modifier :Récemment, j'ai remarqué que, pour une raison quelconque, la nouvelle configuration n'est pas appliquée immédiatement. Vous devez d'abord appuyer sur une touche de votre autre clavier, puis testez les touches configurées sur votre clavier modifié. Je ne sais pas pourquoi cela se produit, peut-être une sorte de cache.
Pour tous ceux qui viennent ici de Google et qui souhaitent une réponse plus conforme à ce que le questionneur espérait à l'origine, je connais deux façons de remapper les événements au evdev pour que la modification s'applique à toutes les applications :
-
udev fournit une API pour modifier les entrées de la base de données matérielle qui contrôlent les mappages entre les scancodes et les keycodes. Cette page ArchiWiki, qui contient des instructions, indique explicitement que cela fonctionnera à la fois pour X11 et pour l'entrée console.
L'essentiel est que vous créez une entrée personnalisée dans
/etc/udev/hwdb.d/qui se compose d'un modèle de correspondance d'appareil et de certaines définitions de remappage scancode à keycode, puis exécutezsystemd-hwdb updatepour reconstruire la base de données etudevadm triggerappliquez-le sans redémarrage. -
Étant donné que Wayland n'utilise pas le sous-système de clavier de X11 et que les principaux compositeurs de Wayland comme GNOME Shell et Weston n'implémentent pas d'interfaces utilisateur pour configurer les aspects pertinents de libinput, quelqu'un a écrit un démon nommé evdevremapkeys qui résout le problème de la même manière que le pilote d'espace utilisateur G15Daemon pour Logitech Claviers de jeu G15.
(Il avale les événements qu'il a l'intention de remapper, afin que rien d'autre qui écoute sur l'appareil ne puisse les voir, puis émet les événements corrigés via le
uinputAPI pour créer des périphériques d'entrée au niveau du noyau à partir de l'espace utilisateur.)