Jak zdobyć kody dostępu dla Xmodmap?

Próbuję użyć xmodmapdo mapowania Alt/ Superklawiszy na klawiaturze Dell L100 i mam problem z uzyskaniem kodów.

Na przykład użycie xevnie daje mi kodu dostępu dlaAlt

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   

Dla Right Superklucza xevi showkeypodaj różne kody dostępu - 134i 126odpowiednio.

Co się dzieje z tymi kluczami?

Próbowałem pobrać kody showkey -ki użyć xmodmappliku poniżej, ale dało to dziwną mapę, która odwzorowała bklucz:

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

Istnieje wiele graczy między klawiaturą a procesem, który ostatecznie obsługuje zdarzenie związane z klawiaturą. Wśród głównych elementów krajobrazu znajduje się fakt, że system X ma własną warstwę obsługi klawiatury, a X kojarzy różne „kody klawiszy” z klawiszami niż system podstawowy Linux. showkeyPolecenia pokazujące keycodes w Linux-base-system slangu. Do tego xmodmappotrzebujesz kodów X, które są xevwyświetlane. Tak długo, jak planujesz pracować w X i ponownie powiązać klucz xmodmap, zignoruj showkeysi po prostu słuchaj tego xev, co mówi.

To, czego chcesz szukać w xevwynikach, to bloki takie jak to:

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

xevma tendencję do generowania dużej ilości danych wyjściowych, zwłaszcza gdy poruszasz myszą. Może być konieczne przewinięcie do tyłu, aby znaleźć wyjście, którego szukasz. W poprzednim wyjściu, widzimy, że keysym Alt_Ljest związany z X-kod 64.

Xev powinien działać

Dziwne, mój xev daje zdarzenie KeyPress i KeyRelease dla alt (i dla klawisza Windows, tutaj nazywanego „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

I po prawej:

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

Widzę dwie możliwości:

1. Coś jeszcze całkowicie zjada naciśnięcie klawisza lub rozmywa okno po naciśnięciu klawisza Alt. Spróbuj uruchomić xev na innym pustym serwerze X (np. Po prostu uruchom xinit -- :1, co powinno dać ci X serwer tylko z xterm - nawet nie będzie działał menedżer okien. Wyjście z xterm zamknie sesję).
2. Właśnie przegapiłeś dwa wydarzenia, które Xev wyrzuca.

Łatwy sposób, jeśli znasz nazwę klucza

Inna możliwość: po prostu pobierz kody klawiszy z 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)

Znów są 64 i 108. xmodmap -pmpokaże tylko mapę modyfikatora, która daje również liczby (tym razem w postaci szesnastkowej).

W twoim pytaniu „wykrywam” trzy problemy:

1. Dlaczego xevi showkeyzgłaszać różne kody kluczy?
2. Dlaczego xevnie wyświetla Altsię poprawnie naciśnięty?
3. Jak zamienić Alti Win?

Odnośnie pierwszego pytania: w dzisiejszych czasach, gdy „sterownik” klawiatury w X tak naprawdę nie napędza sprzętu, może po prostu przekazywać kody klawiszy z jądra do rdzenia X, ale tak nie jest. Dodaje 8 do kodu przed przekazaniem go.

Po drugie: coś w twojej sesji X chwyta to Altwydarzenie. Inne odpowiedzi już to obejmują. (Tj. xevNie dostaje wydarzenia, które chciałbyś zobaczyć). Sprawca może być powiązany z menedżerem okien. Wypróbuj bardziej nagą sesję X.

Po trzecie: nie używaj xmodmap. To jest przestarzałe od dekady. Nowi ludzie to XKB i jego narzędzie setxkbmap.

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

Do wymiany, Alta WinXKB ma już przygotowaną opcję. Po prostu dodaj:

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

Jako root uruchom:

showkey -s

... aby zobaczyć, czym jest scancode dla twojego tajemniczego klucza. Mam coś takiego:

# 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 

Nie jestem pewien, dlaczego wydaje się, że jeden klucz generuje dwa skancody. To nie jest keydown / keyup, tak blisko, jak mogłem stwierdzić na podstawie wzoru. Zwróć uwagę na ostrzeżenie, więc możesz chcieć uruchomić to w trybie pojedynczego użytkownika.

Domyślam się, że 0x46 był moim skancode.

Następnie znajdź nieużywany kod dostępu za pomocą:

xmodmap -pke | less

Tutaj widać, że kod 97 nie jest używany w moim systemie:

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

Kod X, którego używa X, i kod, którego używa jądro, są wyłączone BY 8 z „powodów historycznych”. Więc weź 97 - 8 = 89 i użyj 89 z poleceniem setkeycodes (ponownie jako root):

# setkeycodes 46 89

I powinieneś być ustawiony. Potwierdź za pomocą xev, że otrzymujesz zdarzenie Keypress z kodem klucza 97. (chociaż raz powiedziałem plikowi kluczy Fluxboksa, aby używał tego kodu, nie dostałem już zdarzeń KeyPress - może dlatego, że Fluxbox połyka je, gdy z nich korzysta?)

Zauważ, że „setkeycodes” nie przetrwają restartu, więc musisz dodać go do skryptów inicjujących (np. W /etc/rc.local)

Próbowałem to rozwiązać dla siebie i właśnie to rozgryzłem.

Głównym problemem jest to, że nie otrzymujesz zdarzenia dla naciśnięcia klawisza. Patrząc na opublikowany dziennik, widać powód.

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   

Można zobaczyć, że Focus{In,Out}wydarzenia mają modeod Notify{Grab,Ungrab}. Wskazuje to, że klucz był obsługiwany przez inny proces (prawdopodobnie aplikację skrótu / klawisza).

W moim przypadku były to klawisze xbindkeys, ale jeśli używasz środowiska graficznego, prawdopodobnie mają one system przypisywania klawiszy. Aby zobaczyć te zdarzenia, należy zatrzymać / wyłączyć inny program.

Jeśli nie możesz ustalić, który program kradnie kluczowe zdarzenia, najlepszym rozwiązaniem jest rozpoczęcie kolejnej sesji X bez jej uruchamiania. Uruchom następującą komendę, aby rozpocząć kolejną sesję X na wyświetlaczu :1, jeśli jest już zajęta, po prostu zwiększ liczbę na końcu. Możesz oczywiście zmienić terminal na dowolny, który wolisz lub zainstalowałeś w systemie.

xinit /usr/bin/xterm -- :1

Następnie uruchom xevponownie. To powinno dać wynik bez przechwytywania przez inne programy. Zauważ, że menedżer okien, który się uruchamia, jest najechaniem kursorem, więc będziesz musiał umieścić kursor nad oknem xev, aby klucze mogły zostać przechwycone.

Jak powiedziano w tej doskonałej odpowiedzi dubiousjima , kod klucza jest inny, ponieważ istnieje wiele warstw między xev a jądrem.

Miałem ten sam problem ze Alt_Lzniknięciem w XUbuntu 14.04 ( Alt_Rbyło w porządku). Po długim graniu zauważyłem, że showkeyzarejestrowałem naciśnięcie klawisza, ale xevnie zrobiłem tego - to musi być coś w systemie okiennym. Przeszukałem wszystkie ustawienia „Window Manager” i „Window Manager Tweaks” i niczego nie znalazłem. Wreszcie znalazłem błąd Alt_Lna liście skrótów klawiaturowych ( xfce4-keyboard-shortcuts) w „Edytorze ustawień”. „Zresetowałem” to i mam Alt_Lplecy! Zbłąkany Alt_Lskrót nie pojawił się nigdzie indziej niż w „Edytorze ustawień”.