¿Cómo obtener códigos de teclas para xmodmap?

76

Estoy tratando de usar xmodmappara reasignar Alt/ Superteclas en el teclado Dell L100, y tengo problemas para obtener los códigos de teclas.

Por ejemplo, usar xevno me da el código clave paraAlt

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   

Para la Right Superclave, xevy showkeyproporcione diferentes códigos clave, 134y 126respectivamente.

¿Qué está pasando con estos códigos clave?

Intenté obtener códigos clave showkey -ky usar el xmodmaparchivo a continuación, pero eso dio un mapa extraño que reasignó la bclave:

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
Yaroslav Bulatov
fuente
Tengo el mismo problema con Alt_L no disparando (pero Alt_R está bien), en XUbuntu 14.04. ¿Qué sistema estás usando?
Paul Price

Respuestas:

54

Hay muchos jugadores entre su teclado y el proceso que finalmente maneja el evento del teclado. Entre las piezas principales del panorama se encuentra el hecho de que el sistema X tiene su propia capa de manejo de teclado, y X asocia diferentes "códigos de teclas" con las teclas que su sistema base Linux. El showkeycomando le muestra los códigos clave en la jerga del sistema base de Linux. Para xmodmapusted necesita los códigos de teclas X, que son lo que xevse muestra. Siempre que planee trabajar en X y xmodmapvolver a vincular su clave , ignore showkeysy escuche lo que xevdice.

Lo que desea buscar en su xevsalida son bloques como este:

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

xevtiende a generar una gran cantidad de resultados, especialmente cuando mueve el mouse. Puede que tenga que desplazarse un poco hacia atrás para encontrar la salida que está buscando. En la salida anterior, vemos que la keysym Alt_Lestá asociada con el código de tecla X 64.

dubiousjim
fuente
3
El problema es que no obtengo el evento KeyPress en la tecla de Windows. Probé 3 teclados diferentes y el mismo resultado. De xev solo obtengo FocusOut, FocusIn y KeymapNotify como se ve arriba. Sin embargo, puedo ir y configurar accesos directos a través del administrador de Gnome, y ve la clave de Windows como "Mod4"
Yaroslav Bulatov
La tecla de Windows derecha informa como Mod4, la tecla de Windows izquierda informa como Alt ... lo cual es confuso porque ni siquiera tengo una categoría "Alt" en mi xmodmap.
Yaroslav Bulatov
Prueba Mod1 para Alt.
dubiousjim
2
@YaroslavBulatov parece que su entorno de escritorio se está comiendo la clave (¿posiblemente para abrir su menú principal?)
derobert
3
Puede filtrar los eventos que le ofrece xev. En este caso xev -event keyboardsería suficiente para eliminar la mayor parte del ruido.
Fredrik Wendt
24

xev debería funcionar

Extraño, mi xev ofrece un evento KeyPress y KeyRelease para alt (y para la tecla de Windows, aquí llamada "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

Y el de la derecha:

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

Puedo ver dos posibilidades:

  1. Algo más es comer completamente la tecla presionada, o desenfocar la ventana cuando presionas alt. Intente ejecutar xev en un servidor X vacío (por ejemplo, simplemente ejecute xinit -- :1, lo que debería proporcionarle un servidor X con solo un xterm; ni siquiera habrá un administrador de ventanas ejecutándose. Salir de xterm cerrará la sesión).
  2. Acabas de perderte los dos eventos en la masa que arroja xev.

Una manera fácil, si sabes el nombre clave

Otra posibilidad: solo obtenga los códigos de clave 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)

Hay 64 y 108 de nuevo. xmodmap -pmle mostrará solo el mapa modificador, que también le da los números (aunque, esta vez, en hexadecimal).

derobert
fuente
15

"Detecto" tres problemas en su pregunta:

  1. ¿Por qué hacer xeve showkeyinformar diferentes códigos de tecla para una clave?
  2. ¿Por qué xevno muestra Altser presionado correctamente?
  3. ¿Cómo intercambiar Alty Win?

Con respecto a la primera pregunta: en estos días, donde el "controlador" del teclado en X realmente no maneja el hardware, podría simplemente pasar los códigos clave desde el núcleo al núcleo X, pero no lo hace. Agrega 8 al código clave antes de pasarlo.

Segundo: Algo en tu sesión X está tomando el Altevento. Las otras respuestas cubren esto ya. (Es decir xev, no obtiene el evento que le gustaría ver). El culpable podría estar relacionado con su administrador de ventanas. Prueba una sesión X más desnuda.

Tercero: no usar xmodmap. Ha estado desactualizado por una década. Los nuevos chicos son XKB y su herramienta setxkbmap.

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

Para intercambiar Alty Winya hay una opción preparada en XKB. Solo agrégalo:

$ setxkbmap -option altwin:swap_alt_win
$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us
variant:    altgr-intl
options:    altwin:swap_alt_win,caps:backspace
Robert Siemer
fuente
¿Cómo haces que el setxkbmapcambio sea permanente?
Steve Kehlet
Agregue el cambio a ~/.xinitrc.
Matthias Braun
11

Como root, ejecuta:

showkey -s

... para ver cuál es el código de escaneo para su clave misteriosa. Tengo algo como esto:

# 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 

No estoy seguro de por qué parece que una clave genera dos códigos de escaneo. No es una cuestión de keydown / keyup, por lo que pude ver por el patrón. Tenga en cuenta la advertencia, por lo que es posible que desee ejecutar esto en modo de usuario único.

Supuse que 0x46 era mi código de escaneo.

A continuación, encuentre un código clave no utilizado con:

xmodmap -pke | less

Aquí puede ver que el código clave 97 no se usa en mi sistema:

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

El código clave que usa X y el código clave que usa el núcleo están APAGADOS POR 8 por "razones históricas". Entonces tome 97 - 8 = 89 y use 89 con el comando setkeycodes (nuevamente como root):

# setkeycodes 46 89

Y deberías estar listo. Confirme con xev que está obteniendo un evento Keypress Event con el código clave de 97. (aunque una vez que le dije al archivo de claves Fluxbox que usara ese código clave ya no recibí eventos KeyPress, ¿tal vez porque Fluxbox los traga cuando los usa?)

Tenga en cuenta que los 'setkeycodes' no sobrevivirán al reinicio, por lo que deberá agregarlo a sus scripts de inicio (por ejemplo, en /etc/rc.local)

Greg
fuente
1
¿Tiene un puntero con respecto a "off by 8 por razones históricas"?
Robert Siemer
Usé su respuesta para asignar el bloqueo de mayúsculas en una tecla de función (F9 específicamente). Esto me permite usar F9 como la clave de prefijo en tmux. Gracias.
Raymond Kroeker
@RobertSiemer tldp.org/HOWTO/Keyboard-and-Console-HOWTO-15.html "A menudo, el número X será 8 más que el número Linux". Mi redacción con "histórico" debe haber sido de otra página de manual.
Greg Bell
11

Estaba tratando de resolver esto por mí mismo y lo descubrí.

El principal problema es que no está obteniendo el evento para presionar la tecla. Mirando el registro que publicó, el motivo es evidente.

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   

Puedes ver los Focus{In,Out}eventos tienen una modede Notify{Grab,Ungrab}. Esto indica que una clave fue manejada por otro proceso (probablemente una aplicación de atajo / combinación de teclas).

En mi caso, fueron xbindkeys, pero si está utilizando un entorno de escritorio, probablemente tengan un sistema de combinación de teclas. Para ver estos eventos es xev, deberá detener / deshabilitar el otro programa.

Si no puede determinar qué programa está robando los eventos clave, la mejor solución es iniciar otra sesión X sin que se ejecute. Ejecute el siguiente comando para iniciar otra sesión de X en la pantalla :1, si ya está tomada, aumente el número al final. Por supuesto, puede cambiar el terminal a lo que prefiera o tenga instalado en su sistema.

xinit /usr/bin/xterm -- :1

Luego corre de xevnuevo. Eso debería darte el resultado sin que otros programas lo capturen. Tenga en cuenta que el administrador de ventanas que se inicia es el enfoque de desplazamiento, por lo que deberá colocar el cursor sobre la ventana xev para que se capturen las teclas.


Como se dijo en esta excelente respuesta de dubiousjim , el código clave es diferente porque hay muchas capas entre xev y el núcleo.

Kevin Cox
fuente
4

Tuve el mismo problema con la Alt_Ldesaparición en XUbuntu 14.04 ( Alt_Restaba bien). Después de mucho jugar, observé que showkeygrabé el golpe de teclado, pero xevno lo hice --- tenía que ser algo en el sistema de ventanas. Recorrí todas las configuraciones "Window Manager" y "Window Manager Tweaks", y no encontré nada. Finalmente, encontré un parásito Alt_Len la lista de atajos de teclado ( xfce4-keyboard-shortcuts) en el "Editor de configuraciones". Yo "reinicio" eso, ¡y estoy de Alt_Lespaldas! El Alt_Lacceso directo perdido no apareció en ningún otro lugar excepto en el "Editor de configuraciones".

Paul Price
fuente