Linux Mint MATE i zagadka polskiej klawiatury
Stworzyłem kiedyś wpis na temat ustawiania języka polskiego na systemie Linux Mint.
I niby wszystko fajnie – ustawienia działały, w każdym przypadku podałem sposób graficzny i konsolowy – ale te dwa sposoby nie do końca się ze sobą pokrywały.
Przykładem ustawianie polskiego układu klawiatury. W przypadku sposobu konsolowego działało polecenie:
setxkbmap pl
…Ale tylko do czasu wylogowania i ponownego zalogowania, potem trzeba je było powtórzyć. Sposób graficzny sprawiał zaś, że na dolnym pasku na stałe zagościła ikonka pozwalająca się przełączać między układami.
Co można zrobić, żeby sposób konsolowy w stu procentach pokrył się z graficznym? Spróbuję to zbadać w tym miniwpisie, na systemie Linux Mint w wariancie MATE.
Tę samą rzecz próbowałem zbadać na Cinnamonie, innym głównym wariancie Minta.
Tam jednak odbiłem się na etapie dodawania ikony do dolnego paska, bo nie znalazłem zmian w żadnym konkretnym pliku konfiguracyjnym. Zapewne zachodziła jakaś komunikacja między procesami, której nie ogarniam. Jeszcze.
Spis treści
Śledztwo
Zacząłem od uruchomienia zwykłego okna, przez które na Mincie MATE można zmienić układ klawiatury. To właśnie zrobiliby zwykli użytkownicy, klikając w interfejs. Zgodnie z instrukcją ze wspomnianego na początku wpisu o spolszczaniu.

Ustalenie programu i procesu
Na tym etapie warto było sprawdzić, jaki program tak naprawdę stoi za widocznym oknem. W tym celu uruchomiłem konsolę kombinacją Ctrl+Alt+T i wpisałem polecenie:
xprop
Kiedy je wykonałem, naciskając Enter, kursor zmienił się w krzyżyk. Kliknąłem okno z układem klawiatury, żeby wyświetlić dokładne informacje. Pokazały się między innymi takie:
_NET_WM_PID(CARDINAL) = 2452
WM_CLASS(STRING) = "mate-keyboard-properties"
Tekst na dole to nazwa programu stojącego za widocznym oknem – mate-keyboard-properties. Zatem gdzieś na moim systemie znajduje się plik o takiej nazwie. Zaś w nim – cały kod, jaki komputer przetwarza w tle, kiedy pracuję sobie w tym oknie.
Liczba na górze to natomiast identyfikator procesu. Unikalne oznaczenie programu działającego w danym momencie.
Można powiedzieć, że program to ogólny model samolotu (np. F16), zaś proces to konkretny samolot, który wzbił się w powietrze (potencjalnie jeden z wielu). Podczas lotu zwracają się do niego tylko po numerze.
Sprawdzenie kodu programu (ślepy zaułek)
Mając nazwę programu, mogłem ustalić, gdzie dokładnie się znajduje. Wyszukałem go takim poleceniem:
locate mate-keyboard-properties
Wyskoczyły dwie rzeczy:
Ta druga miała w tekście man, co sugerowało skrót od manual, czyli jakąś instrukcję. Nie interesowało mnie to.
Z kolei pierwsza rzecz miała w ścieżce bin (skrót od binary, czyli dosłownie „zero-jedynkowy”; w praktyce chodzi jednak o program), więc to raczej ona stała za aktywnym oknem.
Spróbowałem odczytać zawartość pliku:
less /usr/bin/mate-keyboard-properties
W idealnym przypadku byłby to jakiś skrypt Pythona i moim oczom ukazałby się czytelny tekst.
Okazało się jednak, że w tym przypadku było inaczej. Był to plik zero-jedynkowy (przed czym less lojalnie mnie ostrzegł). Przeznaczony do czytania przez komputer, nie człowieka.
Mógłbym pogrzebać w internecie za jego kodem źródłowym, ale w ten sposób odszedłbym od idei szperania domyślnymi narzędziami. Zatem uznałem zerkanie w kod programu za ślepy zaułek. Pozostała analiza tego, co robi w praktyce.
Analiza programem strace
Linux posiada świetne narzędzie o nazwie strace (czyt. es-trejs albo strejs), pozwalające podglądać wszystkie interakcje programów z jądrem systemu.
Znając nazwę programu, który chcę śledzić, mógłbym użyć strace’a w takiej postaci:
strace mate-keyboard-properties
…Ale skoro już miałem uruchomione okno, to postanowiłem podczepić się pod nie. Dzięki temu wyniki obserwacji nie byłyby pełne chłamu związanego z inicjalizacją programu – ładowaniem modułów, ikon oraz innych plików pomocniczych przed wyświetleniem okna.
Do podłączenia się pod rzecz działającą przydaje się ID procesu. Ustaliłem je wcześniej – 2452.
Ostatecznie użyłem takiego polecenia:
strace -p 2452 -o keyboard.txt -f -v
-p NUMER śledzi konkretny proces, -o PLIK zapisuje wyniki do wskazanego pliku, -f śledzi również procesy-dzieci, zaś -v każe zbierać szczegółowe informacje.
…Niestety wyświetliło komunikat o błędzie.
To dlatego, że Linux wymaga uprawnień administratora, żeby zaglądać do innych uruchomionych programów. Takie przydatne zabezpieczenie.
Żeby zyskać te uprawnienia, musiałem dopisać na początku polecenia sudo:
sudo strace -p 2452 -o keyboard.txt -f -v
Po wykonaniu komendy na typowym Linuksie powinno zapytać o hasło. U mnie nie pytało, bo testowałem w trybie live USB.
Dopisałem, uruchomiłem polecenie. Zadziałało już bez błędów, strace zaczął śledzić. Następnie wyklikałem we wciąż aktywnym oknie polski układ klawiatury, potem je zamknąłem. Za kulisami powinna zajść jakaś zmiana.
Strace również przestał notować. Mogłem przeszukać stworzony przez niego plik w poszukiwaniu tropów.
Szperanie w zapiskach strace’a
Na tym etapie musiałem zadać sobie pytanie – czego dokładnie szukam?
Skoro ustawienia klawiatury potrafiły przetrwać wylogowanie, to zakładałem, że są czymś trwałym. Czyli zapewne: zapisanym do jakiegoś miejsca na moim systemie. Zapewne do pliku (bo na Linuksie prawie wszystko jest plikiem).
W takim razie naturalną ścieżką wydawało się sprawdzenie interakcji z plikami. Za ich otwieranie odpowiada polecenie (właściwie wywołanie systemowe) o nazwie openat.
Poszukałem jego wystąpień w zapisanych wynikach strace’a:
grep openat keyboard.txt
Znalazło mi różne otwierane pliki. Niektóre miały w swojej ścieżce fonts i rozszerzenia .ttf, czyli były czcionkami – nieciekawe. Podobnie z tymi, które miały w nazwie icons.
Potencjalnie ciekawe były te, które miały w ścieżce /X11/xkb/ – sugerowało to jakieś systemowe ustawienia klawiatury.
Najbadziej zaciekawiły mnie natomiast interakcje z takimi plikami:
To dlatego, że wprost miałem w nazwie .config. Czyli konfiguracja – czyli to, czego szukałem.
Dconf i analiza ustawień
Wspomniany plik dconf/user jest czymś w rodzaju rejestru z Windowsa – to nie prosty, czytelny, tekstowy plik, lecz uporządkowana baza danych, zbliżona strukturą do drzewka.
Trzeba z nią „rozmawiać” przez odpowiednie narzędzie. Jest nim programik konsolowy, który sam również nazywa się dconf.
Warstwy tej bazy dałoby się eksplorować jedną po drugiej poleceniem dconf list:
-
dconf list /pokazałoby katalogi nadrzędnecom/iorg/(ew. parę innych); - potem
dconf list /com/pozwoliłoby zajrzeć do pierwszego z nich…
Takie szukanie krok po kroku byłoby jednak strasznie żmudne. Dlatego bardzo przydaje się polecenie pokazujące całą zawartość bazy naraz.
Zakładałem, że ręczne wybranie układu klawiatury wpływa na jakieś ustawienie w bazie. Chciałem porównać stan po zmianie z początkowym, przed jakimikolwiek zmianami.
Dlatego dla pewności wyłączyłem komputer i załadowałem z pendrive’a nowego, czystego Minta. Od razu po załadowaniu zrobiłem pełen zrzut bazy do pliku nazwanego umownie dconf0.txt:
dconf dump / > dconf0.txt
Następnie uruchomiłem okno z ustawieniami klawiatury, dodałem i wybrałem polski układ. Po czym zrobiłem kolejny zrzut – tym razem, jak zakładałem, zmienionej bazy (zwróćcie uwagę na inną nazwę pliku):
dconf dump / > dconf1.txt
Na koniec pozostało porównać oba pliki:
diff dconf0.txt dconf1.txt
Zobaczyłem, że istotnie zaszły pewne zmiany:
Strzałki w prawo (>) sugerują, że te linijki zostały dodane w nowszej wersji. W nawiasach kwadratowych widać tu nazwy kategorii, zaś poniżej ustawienia (w formacie nazwa=wartość).
Rzeczy z kategorii drugiej mniej mnie interesowały, bo słowo preview sugerowało, że to jakiś podgląd klawiatury.
Przypadek pierwszy wydawał się natomiast strzałem w dziesiątkę:
- kategoria
org/mate/desktop/peripherals/keyboard/kbd, - nazwa
layouts, - wartość
['pl', 'us'].
Tworzenie polecenia konsolowego
Programik dconf pozwala nie tylko przeglądać, ale również edytować opcje. Mogłem teraz łatwo stworzyć własne polecenie dodające polski układ klawiatury.
Wymagało to jednak paru modyfikacji:
- Musiałem dodać ukośnik (
/) na początku nazwy kategorii, żeby przedstawić ją jako pełną ścieżkę „od początku”. -
Ustawianą wartość musiałem umieścić w dodatkowych cudzysłowach.
Inaczej nawiasy kwadratowe byłyby traktowane jako znaki specjalne. Musiałem przy tym użyć podwójnych cudzysłowów, bo pojedyncze już były w środku.
Ostateczne polecenie:
dconf write /org/mate/desktop/peripherals/keyboard/kbd/layouts "['pl','us']"
Mogę użyć tego w konsoli zaraz po załadowaniu świeżego systemu Mint MATE. Zyskuję przełącznik na dolnym pasku, który po kliknięciu zmienia układ klawiatury z angielskiego na polski (i vice versa).
Jeśli nie zależy mi w ogóle na układzie angielskim, to mogę zostawić sam polski (nadal trzymając się formatu listy w nawiasach kwadratowych):
dconf write /org/mate/desktop/peripherals/keyboard/kbd/layouts "['pl']"
Wówczas nie będzie żadnego przełącznika na pasku (nie byłby potrzebny), za to polskie litery zaczną działać.
Co najważniejsze – ta zmiana przetrwa wylogowanie i ponowne zalogowanie. W przeciwieństwie do poprzedniego setxkbmap pl.
Jak sugeruje słowo mate widoczne w ścieżce – polecenie zadziałałoby tylko na wariancie Mint MATE. Nie miałoby przełożenia na Minta Cinnamona ani na inne Linuksy.
Podsumowanie
Linux bywa bardzo przyjazny dla swoich użytkowników, oferując intuicyjne interfejsy graficzne. Czasem jednak warto poszukać konsolowych odpowiedników, zwłaszcza jeśli chce się coś zautomatyzować.
Podczas mojego małego śledztwa użyłem zestawu kultowych programów – xprop, strace, grep, less, diff – żeby dojść do tego, jakie zmiany zachodzą podczas wybierania polskiego układu klawiatury w Centrum Sterowania.
Okazało się, że zmieniają się wówczas ustawienia w konkretnym pliku. Zmianę da się łatwo odtworzyć w świecie konsoli z użyciem programu dconf.
Efektem końcowym jest komenda konsolowa pozwalająca szybko (i trwale!) włączać polski układ klawiatury na systemie Mint MATE.
Opis swoich działań, krok po kroku, zamieszczam tutaj. Mam nadzieję, że pokaże to osobom wchodzącym w świat Linuksa, że zaglądanie za jego kulisy bywa proste i satysfakcjonujące ![]()