Fingerprint reader on ThinkPad T480s

Wstęp

ThinkPad T480s ma wbudowany czytnik linii papilarnych Synaptics o ID 06cb:009a (“Metallica MIS”, match-in-sensor). Domyślny libfprint w Ubuntu 26.04 go nie obsługuje — fprintd i libpam-fprintd są zainstalowane fabrycznie, ale bez pasującego sterownika nic nie wykryją. Poniżej cała ścieżka, która faktycznie zadziałała, razem z dwoma pułapkami po drodze (autosuspend USB i globalny common-auth), na które warto się przygotować od razu, zamiast dochodzić do nich metodą prób i błędów.

Krok 1: Potwierdź model czytnika

lsusb | grep -i synaptics

Szukamy ID 06cb:009a. Dla tego właśnie modelu standardowy libfprint nie ma sterownika — jedyna działająca opcja to reverse-engineered python-validity.

Krok 2: Podmień sterownik na python-validity

sudo apt remove -y fprintd libpam-fprintd
sudo add-apt-repository -y ppa:ubuntuhandbook1/open-fprintd
sudo apt update
sudo apt install -y open-fprintd fprintd-clients python3-validity
sudo systemctl enable --now python3-validity.service
sudo systemctl enable --now open-fprintd-resume.service open-fprintd-suspend.service

Krok 3: Wyłącz USB autosuspend dla czytnika

Bez tego czytnik po ~2 sekundach bezczynności usypia na poziomie USB, a python-validity nie budzi go automatycznie (usługi resume/suspend z kroku 2 reagują tylko na pełne uśpienie systemu, nie na zwykły autosuspend). Objaw: czytnik w ogóle nie reaguje, a w logu journalctl -u open-fprintd widać w pętli The service is suspended / offline, delay the call.

⚠️

Autosuspend USB Sprawdź to od razu, zanim zaczniesz enrollować palec — inaczej łatwo pomylić brak reakcji sensora z błędną instalacją sterownika.

echo 'ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="06cb", ATTR{idProduct}=="009a", TEST=="power/control", ATTR{power/control}="on"' | sudo tee /etc/udev/rules.d/99-fprint-no-autosuspend.rules

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=usb
sudo systemctl restart python3-validity.service open-fprintd.service

Krok 4: Zarejestruj odcisk

fprintd-enroll

Domyślnie zapisuje prawy wskazujący. Żeby wskazać inny palec:

fprintd-enroll -f left-thumb

Dostępne nazwy: left-thumb, left-index-finger, left-middle-finger, left-ring-finger, left-little-finger i analogicznie dla right-*.

Test bez logowania:

fprintd-verify

Krok 5: Włącz odcisk w PAM — ale ostrożnie

sudo pam-auth-update --enable fprintd

To dopisuje pam_fprintd.so do /etc/pam.d/common-auth, czyli pliku dołączanego przez wszystkie usługi PAM w systemie — także gdm-password, sudo, su. Efekt uboczny: GDM ma już własną, dedykowaną ścieżkę gdm-fingerprint z wpisanym na stałe pam_fprintd.so, więc odcisk na ekranie blokady działał od razu. Ale wpisywanie hasła też zaczęło przechodzić przez common-auth, a więc też robiło pełną, do 10-sekundową próbę odczytu palca (max_tries=1 timeout=10), zanim w ogóle sprawdziło hasło. Tyle samo dotyczyło sudo w terminalu.

🚨

Nie zostawiaj fprintd w common-auth, jeśli GDM już ma gdm-fingerprint Sprawdź cat /etc/pam.d/gdm-fingerprint — jeśli tam już jest pam_fprintd.so, to wpis w common-auth jest zbędny i tylko spowalnia każde logowanie hasłem w systemie.

Rozwiązanie — usunąć fprintd z globalnego stosu:

sudo pam-auth-update --remove fprintd

Po tym odcisk na ekranie blokady dalej działa (bo gdm-fingerprint ma go zaszytego na stałe), a wpisywanie hasła — w GDM i w sudo — znowu jest natychmiastowe.

Zarządzanie odciskami

fprintd-list $USER      # lista zarejestrowanych odcisków
fprintd-delete $USER    # usuń wszystkie odciski danego użytkownika

Podsumowanie

Dla Synaptics 06cb:009a na ThinkPadzie T480s: python-validity + open-fprintd zamiast domyślnego fprintd, wyłączony USB autosuspend dla urządzenia, i odcisk włączony wyłącznie tam, gdzie faktycznie ma sens — nie przez globalny common-auth, tylko przez dedykowaną ścieżkę GDM (gdm-fingerprint), która i tak już go obsługuje.