Wie bekomme ich Keycodes für xmodmap?

Ich versuche, / keys auf der Dell L100-Tastatur neu xmodmapzuzuordnen , und habe Probleme beim Abrufen der Schlüsselcodes.AltSuper

Wenn Sie zum Beispiel verwenden, xeverhalte ich keinen Schlüsselcode fürAlt

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   

Für Right SuperSchlüssel, xevund showkeyverschiedene keycodes geben - 134und 126jeweils.

Was ist mit diesen Schlüsselcodes los?

Ich habe versucht, Schlüsselcodes von showkey -kund mithilfe der folgenden xmodmapDatei abzurufen, aber das ergab eine seltsame Karte, die den bSchlüssel neu zugeordnet hat:

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

Es gibt eine Menge Spieler zwischen Ihrer Tastatur und dem Prozess, der das Tastaturereignis abschließt. Zu den Hauptelementen der Landschaft gehört die Tatsache, dass das X-System über eine eigene Tastaturhandhabungsebene verfügt und X den Schlüsseln andere "Schlüsselcodes" zuordnet als Ihr Linux-Basissystem. Der showkeyBefehl zeigt Ihnen die Schlüsselcodes in der Sprache des Linux-Basissystems. Dafür xmodmapbenötigen Sie die X-Tastencodes, die angezeigt werden xev. Solange Sie planen, in X zu arbeiten und Ihren Schlüssel neu zu binden xmodmap, ignorieren Sie showkeysund hören Sie nur, was xevsagt.

Was Sie in Ihrer xevAusgabe suchen möchten, sind Blöcke wie diese:

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

xevneigt dazu, eine Menge Output zu generieren, besonders wenn Sie Ihre Maus bewegen. Möglicherweise müssen Sie eine Weile zurückblättern, um die gewünschte Ausgabe zu finden. In der vorherigen Ausgabe sehen wir, dass das keysym Alt_Ldem X-Schlüsselcode zugeordnet ist 64.

xev sollte funktionieren

Seltsamerweise gibt mein xev ein KeyPress- und KeyRelease-Ereignis für alt (und für die Windows-Taste, hier "super" genannt):

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

Und die rechte:

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

Ich sehe zwei Möglichkeiten:

1. Etwas anderes frisst den Tastendruck vollständig oder defokussiert das Fenster, wenn Sie die Alt-Taste drücken. Versuchen Sie, xev auf einem ansonsten leeren X-Server auszuführen (z. B. einfach ausführen xinit -- :1, wodurch Sie einen X-Server mit nur einem X- Term erhalten sollten - es wird nicht einmal ein Fenstermanager ausgeführt. Wenn Sie den X- Term beenden, wird die Sitzung geschlossen).
2. Sie haben gerade die beiden Ereignisse in der Masse verpasst, die xev ausspuckt.

Ein einfacher Weg, wenn Sie den Schlüsselnamen kennen

Eine andere Möglichkeit: Holen Sie sich einfach die Schlüsselcodes von 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)

Da sind wieder die 64 und 108. xmodmap -pmzeigt Ihnen nur die Modifikatorkarte, die Ihnen auch die Zahlen anzeigt (diesmal jedoch in hexadezimaler Darstellung).

Ich "erkenne" drei Probleme in Ihrer Frage:

1. Warum werden für einen Schlüssel unterschiedliche Schlüsselcodes erstellt xevund showkeygemeldet?
2. Warum wird xevnicht Altrichtig gedrückt?
3. Wie tausche ich Altund Win?

Zur ersten Frage: In diesen Tagen, in denen der Tastatur- "Treiber" in X die Hardware nicht wirklich steuert, könnte er nur die Schlüsselcodes vom Kernel an den X-Kern weitergeben, aber dies ist nicht der Fall. Dem Schlüsselcode werden 8 hinzugefügt, bevor er weitergegeben wird.

Zweitens: Etwas in Ihrer X-Sitzung erfasst das AltEreignis. Die anderen Antworten decken dies bereits ab. (Dh xevnicht das Ereignis, das Sie sehen möchten). Möglicherweise hängt der Täter mit Ihrem Fenstermanager zusammen. Versuchen Sie es mit einer nackten X-Sitzung.

Drittens: nicht verwenden xmodmap. Es ist seit einem Jahrzehnt veraltet. Die neuen Leute sind XKB und sein Werkzeug setxkbmap.

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

Für Austausch Altund Wines gibt bereits eine Option in XKB vorbereitet. Füge es einfach hinzu:

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

Führen Sie als root Folgendes aus:

showkey -s

... um zu sehen, was der Scancode für Ihren Mystery Key ist. Ich habe so etwas:

# 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 

Ich bin mir nicht sicher, warum ein Schlüssel zwei Scancodes generiert. Es ist keine Keydown / Keyup-Sache, so nah ich das Muster erkennen kann. Beachten Sie die Warnung, sodass Sie diese möglicherweise im Einzelbenutzermodus ausführen möchten.

Ich vermutete, dass 0x46 mein Scancode war.

Als nächstes finden Sie einen nicht verwendeten Schlüsselcode mit:

xmodmap -pke | less

Hier sehen Sie, dass der Schlüsselcode 97 auf meinem System nicht verwendet wird:

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

Der von X verwendete Schlüsselcode und der vom Kernel verwendete Schlüsselcode sind aus "historischen Gründen" auf OFF BY 8 gesetzt. Nehmen Sie also 97 - 8 = 89 und verwenden Sie 89 mit dem Befehl setkeycodes (wieder als root):

# setkeycodes 46 89

Und du solltest bereit sein. Bestätigen Sie mit xev, dass Sie ein Keypress-Ereignis mit dem Keycode 97 erhalten. (Obwohl ich der Fluxbox-Schlüsseldatei einmal gesagt habe, dass sie diesen Keycode verwenden soll, habe ich keine KeyPress-Ereignisse mehr erhalten - vielleicht, weil Fluxbox sie verschluckt, wenn sie sie verwendet?)

Beachten Sie, dass die 'setkeycodes' einen Neustart nicht überstehen, so dass Sie sie zu Ihren Init-Skripten hinzufügen müssen (z. B. in /etc/rc.local).

Ich habe versucht, dies für mich selbst zu lösen, und ich habe es gerade herausgefunden.

Das Hauptproblem ist, dass Sie das Ereignis für den Tastendruck nicht erhalten. Wenn Sie sich das von Ihnen veröffentlichte Protokoll ansehen, ist der Grund offensichtlich.

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   

Sie können sehen, dass die Focus{In,Out}Ereignisse eine modevon haben Notify{Grab,Ungrab}. Dies zeigt an, dass ein Schlüssel von einem anderen Prozess verarbeitet wurde (wahrscheinlich einer Tastenkombination).

In meinem Fall handelte es sich um xbindkeys, aber wenn Sie eine Desktop-Umgebung verwenden, verfügen diese wahrscheinlich über ein Tastaturbindungssystem. Um diese Ereignisse zu sehen, müssen Sie das andere Programm stoppen / deaktivieren.

Wenn Sie nicht feststellen können, welches Programm die Schlüsselereignisse stiehlt, ist es die beste Lösung, eine weitere X-Sitzung zu starten, ohne dass sie ausgeführt wird. Führen Sie den folgenden Befehl aus, um eine weitere angezeigte X-Sitzung zu starten. :1Wenn dies bereits erfolgt ist, erhöhen Sie einfach die Zahl am Ende. Sie können das Terminal natürlich beliebig ändern oder auf Ihrem System installiert haben.

xinit /usr/bin/xterm -- :1

Dann renn xevnochmal. Das sollte Ihnen das Ergebnis liefern, ohne dass es von anderen Programmen erfasst wird. Beachten Sie, dass der Fenstermanager, der gestartet wird, den Schwebefokus hat, sodass Sie den Cursor über dem xev-Fenster platzieren müssen, damit die Tasten erfasst werden.

Wie in dieser hervorragenden Antwort von dubiousjim gesagt wurde , ist der Schlüsselcode anders, weil es viele Schichten zwischen xev und dem Kernel gibt.

Ich hatte das gleiche Problem mit dem Alt_LVerschwinden in XUbuntu 14.04 ( Alt_Rwar in Ordnung). Nach vielem Spielen habe ich beobachtet, dass showkeyder Tastenanschlag aufgezeichnet wurde, aber xevnicht - es musste etwas im Fenstersystem sein. Ich habe alle "Window Manager" - und "Window Manager Tweaks" -Einstellungen durchsucht und nichts gefunden. Schließlich fand ich einen Fehler Alt_Lin der Liste der Tastaturkürzel ( xfce4-keyboard-shortcuts) im "Einstellungseditor". Ich "setze" das zurück und ich habe meinen Alt_LRücken! Die verirrte Alt_LVerknüpfung wurde nur im "Einstellungseditor" angezeigt.