Zależność układu klawiatury i xmodmap

Używam Xubuntu. Przed zalogowaniem mogę wybrać układ klawiatury. Używam xmodmapdo mapowania niektórych kluczy.

Interesują mnie dwie rzeczy:

1. Jak zmienia się stan mapowania klawiatury (a) po włączeniu laptopa, (b) podczas procesu rozruchu i (c) logowania do systemu (w tych trzech fazach) oraz podczas pracy z systemem (zalogowany).
2. Co powoduje, które symbole będą wyświetlane na ekranie (i wysyłane klawisze kontrolne) podczas poszczególnych faz. Kiedy naciskam jakiś klawisz, wysyła sygnał do sterownika klawiatury (?), A następnie musi być jakiś proces decyzyjny (aplikacje i pliki konfiguracyjne) określający, które symbole będą wyświetlane. Odpowiedzią na to pytanie powinna być lista aplikacji i ścieżek do tych plików konfiguracyjnych (szczególnie interesuje mnie Ubuntu (system oparty na Debianie), ale możesz opisać inny system, ale preferowany jest Ubuntu).

Są tu dwie warstwy: KEYCODE do mapowania KEYSYM i KEYSYM do mapowania tekstu. Istnieje więcej warstw, jeśli policzysz jądro, które musi zamapować skany kodów AT Keyboard na KOD KLUCZOWY w stylu XT lub kod HID klawiatury USB na KOD KODOWY. KEYCODE to po prostu 8-bitowa liczba całkowita bez znaku, którą jądro systemu operacyjnego przekazuje do serwera X11. Może się różnić w zależności od systemów operacyjnych, takich jak Linux i Solaris. W systemie Linux te KODY KODOWE są zazwyczaj takie same, jak używane na starych klawiaturach XT PC. Nowsze komputery z klawiaturą AT, PS / 2 lub USB zwykle po prostu mapują te klawiatury na stary kod XT, aby ułatwić życie.

Surowe kody klawiatury, niezależnie od tego, czy są to XT, AT, PS / 2, czy USB, reprezentują fizyczne położenie na klawiaturze. Klawiatura XT wysyła tylko jeden 8-bitowy numer po naciśnięciu lub zwolnieniu klawisza. Klawisz q na amerykańskiej / brytyjskiej klawiaturze XT wysyła liczbę 16. Na francuskiej klawiaturze ten sam fizyczny klawisz jest oznaczony jako, ale nadal wysyła 16. To wyższe warstwy w systemie operacyjnym nadają mu prawdziwe znaczenie. Po zwolnieniu klawisza na klawiaturze XT wysyłany jest ten sam kod plus 128. W tym przykładzie po naciśnięciu q wysyłana jest 16, ale po zwolnieniu wysyłana jest liczba 142 (16 + 128). Klawiatury AT używają skancodów, które są ciągiem liczb i mogą być dość długie. Kluczowe wydania dodają dodatkowe kody. Na przykład, skancode dla Pause to E1, 1D, 45, E1, 9D, C5. Większość systemów operacyjnych, w tym DOS, Windows, Linux, FreeBSD, a BIOS wszystkie mapują skancody na znacznie prostsze skancody w stylu XT. Ułatwia także obsługę nowszych klawiatur, które używają różnych kodów, takich jak klawiatury USB wysyłające kody HID. Wszystkie kody są odwzorowywane przez system operacyjny na ten sam spójny zestaw kodów, zanim X11 lub aplikacja je zobaczy.

X11 nie zna tej części procesu, po prostu pobiera KEYCODE z jądra i stosuje własne mapowanie, aby przekonwertować ten KEYCODE na KEYSYM. Xmodmap to standardowe narzędzie do kontrolowania tego mapowania. Wiele zachowań mapowania klawiatury jest konfigurowalnych, ale istnieje kilka specjalnych przypadków, takich jak Num Lock, Switch Mode i Caps Lock / Shift Lock, które są mocno zakodowane w X11. Inne aspekty, takie jak Shift, są w rzeczywistości konfigurowalne. Każdy klawisz można zmapować, aby działał jak shift, w przeciwieństwie do przełączania trybu lub Num Lock.

KEYCODE reprezentują klucze fizyczne wysyłane przez jądro systemu operacyjnego. Każdy KEYCODE może być przypisany do 8 możliwych KEYSYMÓW. Używane są tylko 4 i są czasami nazywane poziomami 1-4. Poziom 1 określa KLUCZ, który jest drukowany, gdy nie są aktywne żadne modyfikatory. Są to często małe litery i cyfry. Modyfikatory to KEYCODE, które modyfikują KEYSYM generowany przez inne KEYCODE, gdy modyfikator jest aktywny (wciśnięty lub włączony). Kody klawiszy modyfikatora są również kontrolowane przez Xmodmap. Poziom 2 określa KLUCZ, który ma zostać wysłany po naciśnięciu modyfikatora zmiany biegów. Poziom 3 jest aktywowany po każdym naciśnięciu przełącznika trybu KEYSYM. Poziom 4 jest aktywowany, gdy aktywny jest klawisz Shift i przełącznik trybu.

Po wygenerowaniu KLUCZA można to zinterpretować bezpośrednio, ale najczęściej zostanie przekonwertowane na tekst. Nie wszystkie KEYSYM zamieniają się w tekst lub mogą wpływać tylko na przyszły KEYSYM. Jednym z przykładów jest Shift_L, oczywiście, który nie ma reprezentacji tekstowej, ale istnieje również wiele KLUCZY, które są używane do komponowania innego znaku. Ich lista w moim systemie jest poniżej /usr/share/X11/locale/en_US.UTF-8/Compose. Jednym z takich przykładów jest dead_acute KEYSYM, który po naciśnięciu spróbuje przekształcić następny KEYSYM w ostrą akcentowaną literę. Istnieje standardowe odwzorowanie do przekształcania KEYSYM w Unicode.

Teraz, gdy już to wszystko zostało powiedziane, zauważ, że Xmodmap jest przestarzały i zastąpiony przez XKB, który jest znacznie bardziej wyrafinowany. Wpływa to na sposób mapowania KEYCODE na KEYSYM, ale nie na to, w jaki sposób jądro generuje KEYCODE, ani na to, jak KEYSYM są konwertowane na tekst lub skład, co jest nadal takie samo. XKB można wyłączyć, przywracając zachowanie Xmodmap. Ma również warstwę kompatybilności do obsługi Xmodmap, ale może mieć problemy, ponieważ nie jest w pełni kompatybilna. Zasady XKB są poniżej /usr/share/X11/xkb/i są znacznie bardziej wyrafinowane. Gdzie indziej istnieje dobra dokumentacja na temat tego, jak generuje układy klawiatury do mapowania KEYCODE na KEYSYM.

Jeśli chodzi o konsolę Linux, ma ona własne układy klawiatury, które są przechowywane /usr/share/keymapsi ładowane za pomocą loadkeyspolecenia. W systemie BIOS i we wcześniejszych etapach ładowania programu rozruchowego, w tym GRUB2, mapowanie klawiatury jest dowolną liczbą, na którą BIOS decyduje się zamapować klucz.