Comment obtenir des codes clés pour xmodmap?

J'essaie d'utiliser xmodmappour remapper Alt/ Supertouches sur le clavier Dell L100, et ai du mal à obtenir les codes de touche.

Par exemple, utiliser xevne me donne pas le code de touche pourAlt

FocusOut event, serial 36, synthetic NO, window 0x4a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 36, synthetic NO, window 0x4a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  122 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

Pour la Right Superclé, xevet showkeydonner différents keycodes - 134et 126respectivement.

Que se passe-t-il avec ces codes de touche?

J'ai essayé d'obtenir les codes clés showkey -ket d'utiliser le xmodmapfichier ci-dessous, mais cela a donné une carte étrange qui remappait la bclé:

clear Mod1
clear Control
keycode 125 = Meta_L
keycode 126 = Meta_R
keycode 58 = Control_L
keycode 56 = Control_L
keycode 100 = Control_R
add Control = Control_L Control_R
add Mod1 = Meta_L Meta_R

Il y a beaucoup de joueurs entre votre clavier et le processus qui gère finalement l'événement de clavier. Parmi les éléments majeurs du paysage, il y a le fait que le système X dispose de sa propre couche de gestion du clavier et que X associe différents "codes clés" à des clés différentes de celles de votre système de base Linux. La showkeycommande vous montre les codes clés dans le jargon Linux-base-system. Car xmodmapvous avez besoin des codes clavier X, qui sont ce qui xevest affiché. Tant que vous envisagez de travailler dans X et de relier votre clé avec xmodmap, ignorez showkeyset écoutez ce que vous dites xev.

Ce que vous voulez rechercher dans votre xevsortie sont des blocs comme celui-ci:

KeyPress event, serial 27, synthetic NO, window 0x1200001,
    root 0x101, subw 0x0, time 6417361, (340,373), root:(342,393),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1200001,
    root 0x101, subw 0x0, time 6417474, (340,373), root:(342,393),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

xeva tendance à générer beaucoup de sortie, en particulier lorsque vous déplacez votre souris. Vous devrez peut-être revenir en arrière un peu pour trouver le résultat recherché. Dans la sortie précédente, on voit que l' keysym Alt_Lest associé au X keycode 64.

xev devrait fonctionner

Odd, mon xev donne un événement KeyPress et KeyRelease pour alt (et pour la touche Windows, appelée ici "super"):

KeyPress event, serial 40, synthetic NO, window 0xae00001,
    root 0x2ca, subw 0x0, time 595467354, (98,77), root:(102,443),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0xae00001,
    root 0x2ca, subw 0x0, time 595467453, (98,77), root:(102,443),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Et celui de droite:

KeyPress event, serial 40, synthetic NO, window 0xae00001,
    root 0x2ca, subw 0x0, time 595572876, (75,33), root:(79,399),
    state 0x10, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0xae00001,
    root 0x2ca, subw 0x0, time 595572972, (75,33), root:(79,399),
    state 0x18, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Je peux voir deux possibilités:

1. Quelque chose d'autre est complètement en train de manger la touche ou de défocaliser la fenêtre lorsque vous appuyez sur alt. Essayez d’exécuter xev sur un serveur X vide par exemple (par exemple, lancez-le xinit -- :1, ce qui devrait vous permettre d’obtenir un serveur X avec seulement un xterm - il n’y aura même pas de gestionnaire de fenêtres en cours d’exécution. La fermeture de xterm fermera la session).
2. Vous venez de manquer les deux événements dans la masse que xev crache.

Un moyen facile, si vous connaissez le nom de la clé

Une autre possibilité: il suffit d’obtenir les codes clés de xmodmap:

anthony@Zia:~$ xmodmap -pk | grep -i alt
     64         0xffe9 (Alt_L)  0xffe7 (Meta_L) 0xffe9 (Alt_L)  0xffe7 (Meta_L)
    108         0xffea (Alt_R)  0xffe8 (Meta_R) 0xffea (Alt_R)  0xffe8 (Meta_R)
    204         0x0000 (NoSymbol)       0xffe9 (Alt_L)  0x0000 (NoSymbol)       0xffe9 (Alt_L)
anthony@Zia:~$ xmodmap -pk | grep -i super
    133         0xffeb (Super_L)        0x0000 (NoSymbol)       0xffeb (Super_L)
    134         0xffec (Super_R)        0x0000 (NoSymbol)       0xffec (Super_R)
    206         0x0000 (NoSymbol)       0xffeb (Super_L)        0x0000 (NoSymbol)       0xffeb (Super_L)

Il y a les 64 et 108 encore. xmodmap -pmvous montrera juste la carte de modificateur, qui vous donne également les nombres (bien que, cette fois, en hexadécimal).

Je "détecte" trois problèmes dans votre question:

1. Pourquoi faire xevet showkeysignaler différents codes de clé pour une clé?
2. Pourquoi ne xevmontre pas Altêtre appuyé correctement?
3. Comment échanger Altet Win?

En ce qui concerne la première question: ces jours-ci, lorsque le "pilote" du clavier sous X ne pilote pas vraiment le matériel, il pourrait simplement transmettre les codes de clé du noyau au noyau X, mais ce n’est pas le cas. Il ajoute 8 au keycode avant de le transmettre.

Deuxièmement: quelque chose dans votre session X est en train de saisir l' Altévénement. Les autres réponses couvrent déjà cela. (Ie xevne comprend pas l'événement que vous aimeriez voir). Le coupable pourrait être lié à votre gestionnaire de fenêtres. Essayez une session X plus nue.

Troisièmement: ne pas utiliser xmodmap. Il est dépassé depuis une décennie. Les nouveaux gars sont XKB et son outil setxkbmap.

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us
variant:    altgr-intl
options:    caps:backspace

Pour l’échange Alt, Winil existe déjà une option dans XKB. Ajoutez-le simplement:

$ setxkbmap -option altwin:swap_alt_win
$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us
variant:    altgr-intl
options:    altwin:swap_alt_win,caps:backspace

En tant que root, lancez:

showkey -s

... pour voir quel est le scancode pour votre clé mystère. J'ai quelque chose comme ça:

# showkey -s
kb mode was RAW
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...

0xc6 
0x46 0xc6 
0xc6 
0x46 0xc6 
0x46 

Vous ne savez pas pourquoi il semble qu'une clé génère deux scancodes. Ce n'est pas une chose de keydown / keyup, autant que je puisse dire d'après le modèle. Notez l'avertissement, vous voudrez peut-être l'exécuter en mode mono-utilisateur.

J'ai deviné que 0x46 était mon scancode.

Ensuite, trouvez un keycode non utilisé avec:

xmodmap -pke | less

Vous pouvez voir ici que le code 97 n'est pas utilisé sur mon système:

keycode  94 = less greater less greater bar brokenbar
keycode  95 = F11 XF86Switch_VT_11 F11 XF86Switch_VT_11
keycode  96 = F12 XF86Switch_VT_12 F12 XF86Switch_VT_12
keycode  97 =
keycode  98 = Katakana NoSymbol Katakana
keycode  99 = Hiragana NoSymbol Hiragana

Le code d'activation utilisé par X et le code d'activation utilisé par le noyau sont OFF BY 8 pour des "raisons historiques". Prenez donc 97 - 8 = 89 et utilisez 89 avec la commande setkeycodes (à nouveau en tant que root):

# setkeycodes 46 89

Et vous devriez être prêt. Confirmez avec xev que vous obtenez un événement Keypress avec le code d'activation 97. (bien qu'une fois que j'ai dit au fichier de clés de Fluxbox d'utiliser ce code d'activation, je n'avais plus d'événements KeyPress - peut-être parce que Fluxbox les avalait quand il les utilisait?)

Notez que les 'setkeycodes' ne survivront pas au redémarrage, vous devrez donc les ajouter à vos scripts d'initialisation (par exemple, dans /etc/rc.local)

J'essayais de résoudre ce problème par moi-même et je venais de le comprendre.

Le problème principal est que vous n'obtenez pas l'événement pour la pression de touche. En regardant le journal que vous avez posté, la raison est évidente.

FocusOut event, serial 36, synthetic NO, window 0x4a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 36, synthetic NO, window 0x4a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  122 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

Vous pouvez voir les les Focus{In,Out}événements ont un modedes Notify{Grab,Ungrab}. Cela indique qu'une clé a été gérée par un autre processus (probablement une application de raccourci / de raccourci clavier).

Dans mon cas, c’était xbindkeys, mais si vous utilisez un environnement de bureau, ils ont probablement un système de raccourci clavier. Afin de voir ces événements est xev, vous devrez arrêter / désactiver l'autre programme.

Si vous ne pouvez pas déterminer quel programme vole les événements clés, la meilleure solution consiste à démarrer une autre session X sans l'avoir exécutée. Exécutez la commande suivante pour démarrer une autre session X :1, si cela est déjà pris, augmentez simplement le nombre à la fin. Vous pouvez bien entendu changer le terminal selon vos préférences ou votre installation sur votre système.

xinit /usr/bin/xterm -- :1

Puis courez xevencore. Cela devrait vous donner le résultat sans que cela soit capturé par d'autres programmes. Notez que le gestionnaire de fenêtres qui se lance est le survol actif. Vous devrez donc placer votre curseur au-dessus de la fenêtre xev pour que les clés soient capturées.

Comme l'a dit dubiousjim dans cette excellente réponse , le code clé est différent car il y a beaucoup de couches entre xev et le noyau.

J'ai eu le même problème avec la Alt_Ldisparition dans XUbuntu 14.04 ( Alt_Rc'était bien). Après avoir beaucoup joué, j'ai constaté que showkeyla frappe était enregistrée, mais xevpas - il devait y avoir quelque chose dans le système de fenêtre. J'ai parcouru tous les paramètres du "Gestionnaire de fenêtres" et du "Gestionnaire de fenêtres", sans rien trouver. Enfin, j'ai trouvé un écart Alt_Ldans la liste des raccourcis clavier ( xfce4-keyboard-shortcuts) dans "Settings Editor". Je "réinitialise" cela, et j'ai le Alt_Ldos! Le Alt_Lraccourci parasite ne s'est affiché nulle part ailleurs que dans "l'éditeur de paramètres".