Ich habe die Definition von Mod1via geändert xmodmap, sodass es nicht eingeschlossen wird ALT_R(um zu verstehen, warum Sie nach unten scrollen müssen). Das aktuelle Layout der Modifikatoren finden Sie unten. Obwohl es ALT_Rnicht an der Definition von beteiligt ist mod1, zeigen von erstellte Aufzeichnungen xev, dass auf (definiert als 8 in ) KeyEvent.stategesetzt wird , wenn eine der Alt-Tasten gedrückt wird.mod1Mask/usr/include/X11/X.h
Wenn xmodmaskdies ALT_Rnicht der Fall ist mod1, warum wird dann + Xgemeldet , als ob es so wäre?ALT_Rf
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
Die folgende Sequenz ist ALT_L+ fgefolgt von ALT_R+ f.
KeyPress event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4126632, (85,488), root:(86,489),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4126850, (85,488), root:(86,489),
state 0x8, keycode 41 (keysym 0x66, f), same_screen YES,
XLookupString gives 1 bytes: (66) "f"
XmbLookupString gives 1 bytes: (66) "f"
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4126930, (85,488), root:(86,489),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4126969, (85,488), root:(86,489),
state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
XLookupString gives 1 bytes: (66) "f"
XFilterEvent returns: False
KeyPress event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4127907, (85,488), root:(86,489),
state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4128123, (85,488), root:(86,489),
state 0x8, keycode 41 (keysym 0x66, f), same_screen YES,
XLookupString gives 1 bytes: (66) "f"
XmbLookupString gives 1 bytes: (66) "f"
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4128164, (85,488), root:(86,489),
state 0x8, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0x1000001,
root 0xc0, subw 0x0, time 4128203, (85,488), root:(86,489),
state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
XLookupString gives 1 bytes: (66) "f"
XFilterEvent returns: False
Hintergrund:
Ich habe eine Anwendung, die ALT_R+ verwendet ENTER, um eine Funktion auszuführen. Wenn ich diese Anwendung in Xmonad verwende, löst die Kombination Mod1+ ENTERdie Funktion „Aktuelles Fenster mit dem Hauptfenster tauschen“ aus. Standardmäßig sind ALT_Lund ALT_Rauf abgebildet Mod1.
In meinem .xinitrchabe ich vor dem Start von Xmonad meine Tastenzuordnung mit xmodmapso geändert, dass ALT_Rnicht Teil der Definition ist . Trotzdem führt Xmonad beim Eingeben von + Mod1immer noch das Fensteraustauschverhalten aus . Xmonad scheint nicht zu wissen, dass nicht mehr enthält .ALT_RENTERMod1ALT_R
Hier ist mein.xinitrc
# Java's GUI can't handle some non-reparenting window managers like
# Xmonad without being told how to behave
export _JAVA_AWT_WM_NONREPARENTING=1
# The right Alt key is useful in IntelliJ, tell Xmonad to ignore it
xmodmap ~/.Xmodmap
# Start Xmonad
xmonad
Hier ist die Ausgabe xmodmapnach dem Start von Xmonad wie oben.
Ich habe die Sequenz mit aufgezeichnet xevund bestätigt, dass das ENTERnie registriert wird. Stattdessen treten mehrere FocusIn/ FocusOutEreignisse auf, nachdem das ALT_Raufgezeichnet wurde.
KeyPress event, serial 32, synthetic NO, window 0x1200001,
root 0xc0, subw 0x0, time 1432589, (92,374), root:(93,375),
state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
FocusOut event, serial 32, synthetic NO, window 0x1200001,
mode NotifyGrab, detail NotifyAncestor
PropertyNotify event, serial 32, synthetic NO, window 0x1200001,
atom 0x155 (WM_STATE), time 1433760, state PropertyNewValue
FocusOut event, serial 32, synthetic NO, window 0x1200001,
mode NotifyUngrab, detail NotifyPointer
FocusIn event, serial 32, synthetic NO, window 0x1200001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 32, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 16 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyRelease event, serial 32, synthetic NO, window 0x1200001,
root 0xc0, subw 0x0, time 1434117, (92,374), root:(93,375),
state 0x8, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Antwort1
Wenn Alt_R keinem anderen Modifikator zugewiesen ist, wird standardmäßig anscheinend Mod1Mask verwendet.
Das einfache Aufheben der Bindung des richtigen Alts in meinem Xmodmap reichte nicht aus, um es dazu zu bringen, den Status 0x8 nicht mehr zu melden. Ich musste es an einen anderen Modifikator binden (ich wählte Mod3, da es sowieso leer war), und dann begann Xev, den Status 0x20 zu melden.
Allerdings handelt es sich dabei eher um einen Workaround als um eine Lösung.