
Cambié la definición de Mod1vía xmodmap
para no incluirla ALT_R(para entender por qué, desplácese hasta el final). El diseño actual de los modificadores se encuentra a continuación. A pesar de ALT_Rno participar en la definición de mod1, las grabaciones producidas por xev
muestran que KeyEvent.state
se establece en mod1Mask
(definido como 8 en /usr/include/X11/X.h
) cuando se presiona cualquiera de las teclas Alt.
Si xmodmask
dice que ALT_Rno lo es mod1, ¿por qué X
informa ALT_R+ fcomo si lo fuera?
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)
La siguiente secuencia es ALT_L+ fseguida de 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
Fondo:
Tengo una aplicación que utiliza ALT_R+ ENTERpara realizar una función. Cuando se utiliza esta aplicación en Xmonad, la combinación Mod1+ ENTERactiva la función "intercambiar la ventana actual con la ventana maestra". De forma predeterminada, ALT_Ly ALT_Restán asignados a Mod1.
En mi .xinitrc
, antes de iniciar Xmonad, modifiqué mi mapa de claves de xmodmap
tal manera que ALT_Rno forma parte de la Mod1definición. A pesar de esto, Xmonad todavía realiza el comportamiento de intercambio de ventanas al ingresar ALT_R+ ENTER. Xmonad parece no ser consciente de que Mod1ya no incluye archivos ALT_R.
Aquí está mi.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
Aquí está el resultado xmodmap
después de que se inicia Xmonad.
Grabé la secuencia xev
y confirmé que ENTERnunca se registró. En cambio, se producen varios eventos FocusIn
/ después de que se registra.FocusOut
ALT_R
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
Respuesta1
Parece que si Alt_R no está asignado a ningún otro modificador, el valor predeterminado es Mod1Mask.
Simplemente desvincular el alt derecho en mi Xmodmap no fue suficiente para que dejara de informar el estado 0x8, tuve que vincularlo a otro modificador (elegí Mod3 porque de todos modos estaba vacío) y luego xev comenzó a informar el estado 0x20.
Aunque es más una solución alternativa que una solución.