In meinem Fujitsu Notebook steckt ein Fingerabdruckleser. Ein NEXT Biometrics NB-2020-U, USB ID 298d:2020. Unter Windows funktioniert er, unter Linux nicht. Kein Treiber, kein Support, nichts. Das Gerät taucht in lsusb auf, wird aber von keinem Treiber erkannt. Im libfprint Wiki steht es auf der Liste der nicht unterstützten Geräte. Dort steht es schon eine Weile.
Das hat mich gestört.
libfprint kennt den NB-1010-U. Das ist ein externer USB Fingerabdruckleser von NEXT Biometrics, der seit einiger Zeit einen funktionierenden Treiber hat. Der NB-2020-U ist die eingebettete Variante desselben Sensors, gedacht für den Einbau in Notebooks. Wenn man sich Teardown Reports ansieht, etwa von System Plus Consulting oder Yole Group, dann stellt man fest: Beide Geräte verwenden den identischen Sensor Die. Gleiche Technik, anderes Gehäuse.
Das war der erste Anhaltspunkt. Wenn die Hardware gleich ist, sollte auch das USB Protokoll gleich sein. Und wenn das Protokoll gleich ist, sollte der vorhandene Treiber funktionieren.
Bevor ich aber einfach auf Verdacht losprogrammiert habe, wollte ich es absichern. Ich habe NEXT Biometrics direkt angeschrieben. Kevin Hung, Director FAE bei NEXT Biometrics, hatte mir bereits 2022 auf eine Anfrage zu Linux Treibern geantwortet. Damals war sein Vorschlag, über Fujitsu zu gehen. Das führte ins Leere. Diesmal habe ich konkret angeboten, selbst einen libfprint Treiber zu schreiben, und um das SDK gebeten.
Kevin hat mir daraufhin das NBBiometrics ANF SDK 3.0.0.1384 zugeschickt. Ein komplettes SDK mit Headern, Bibliotheken, Beispielcode und Dokumentation. Das war sehr hilfreich, denn die Header bestätigen einiges. Das SDK nutzt eine einzige Shared Library libNBBiometrics.so für alle Gerätetypen. Der NB-1010-U hat den internen Gerätetyp 200, der NB-2020-U den Typ 202. Beide verwenden dasselbe Scanformat: 180×256 Pixel bei 385 DPI. Die USB Vendor ID ist bei beiden 0x298d, nur die Product ID unterscheidet sich: 0x1010 beim einen, 0x2020 beim anderen.
Wichtig: Das SDK ist proprietär. Für den eigentlichen Treiber habe ich keinen Code daraus verwendet. libfprint akzeptiert nur sauberen, eigenständig entwickelten Code. Das SDK diente ausschließlich als Referenz, um die Protokollkompatibilität zu bestätigen.
Also habe ich es einfach ausprobiert. Den bestehenden nb1010.c Treiber genommen, die USB Product ID 0x2020 zur id_table hinzugefügt und gebaut. Dann auf dem Fujitsu Notebook getestet.
Es funktionierte sofort.
Geräteerkennung, USB Interface Claim, die State Machine für die Fingererkennung, alles lief auf Anhieb. fprintd-enroll hat Fingerabdrücke aufgenommen, fprintd-verify hat sie korrekt verifiziert. Der bestehende Treibercode brauchte keinerlei Anpassungen. Null. Nur die PID in der Tabelle und den Gerätenamen.
Ein Blick auf die USB Deskriptoren bestätigt das Bild. Der NB-2020-U hat exakt dasselbe Endpoint Layout wie der NB-1010-U: Bulk OUT auf Endpoint 0x02, Bulk IN auf Endpoint 0x83. Dazu kommt ein Interrupt Endpoint auf 0x81, den der Treiber nicht verwendet. Die Kommunikation läuft identisch ab.
Der Patch selbst ist entsprechend klein. Drei Dateien, drei Zeilen rein, drei Zeilen raus:
libfprint/drivers/nb1010.c: Die neue PID0x2020wird in dieid_tableeingetragen und derfull_nameauf"NextBiometrics NB-1010-U/NB-2020-U"erweitert.data/autosuspend.hwdb: Der Eintrag298d:2020wird von der Liste der nicht unterstützten Geräte in die Sektion des nb1010 Treibers verschoben.libfprint/fprint-list-udev-hwdb.c: Der Eintrag wird aus der Allowlist der nicht unterstützten Geräte entfernt, da er jetzt vom Treiber abgedeckt wird.
Den Merge Request habe ich bei libfprint upstream eingereicht: MR !569. Die CI Pipeline läuft durch, alle 124 Tests bestehen. Jetzt heißt es warten auf das Review durch die Maintainer.
Für alle, die denselben Fingerabdruckleser in ihrem Notebook haben: Sobald der Patch gemergt und in einer neuen libfprint Version enthalten ist, funktioniert der Sensor out of the box. Enrollment und Verifikation über fprintd laufen sauber. Wer nicht warten möchte, kann den Patch auch jetzt schon selbst auf ein aktuelles libfprint anwenden.
Im selben Fujitsu Notebook meiner Tochter steckt ein NB-2033-U, ein weiterer Fingerabdruckleser aus der gleichen Familie. Der verwendet allerdings ein komplett anderes Protokoll und ließ sich nicht einfach mit dem nb1010 Treiber ansprechen. Den habe ich per Reverse Engineering geknackt.
Lifesaver! Ich hab ein Lifebook E5512 und der Fingerabdruckleser war unter Fedora 41 einfach unsichtbar. Hab mich schon damit abgefunden das er halt nicht geht. Ist der Patch schon in irgendeinem Release von libfprint drin oder muss ich das selber bauen?
Der MR ist noch offen (Stand heute), also selber bauen oder warten bis er gemergt wird. Ist aber wirklich nur drei Zeilen, das kriegt man hin. Bei Fedora am einfachsten mit mock oder rpmbuild das Paket neu bauen.
Found this through the libfprint merge request. Great detective work figuring out the NB-2020-U is essentially the same sensor as the NB-1010-U. I have a Fujitsu U7412 with the same problem, going to try this patch tonight. Would be great if this gets merged upstream so distros can pick it up.
Der Teil mit der SDK-Analyse fand ich am spannendsten. Wie bist du überhaupt darauf gekommen den Windows-Treiber auseinanderzunehmen? Einfach Vermutung oder hattest du nen konkreten Hinweis dass der gleiche Die drin steckt?
steht doch im artikel, gleiche vendor+product id nur andere usb subclass. wenn lsusb dir quasi das gleiche gerät zeigt liegt der verdacht nahe
Danke für den Beitrag und vor allem dafür dass du den Patch upstream eingereicht hast! Genau so sollte Open Source laufen. Hab ein Lifebook U7312, muss mal prüfen welcher Sensor da verbaut ist.
Du schreibst am Ende was vom NB-2033-U — ist das der Nachfolger? Hast du da schon was rausfinden können? In meinem neuen Lifebook (E16 Gen 2) steckt laut lsusb ein „NEXT Biometrics“ Gerät mit ner anderen Product ID, könnte das der 2033er sein.
Würde mich auch intressieren. Wenn die bei NEXT den gleichen Ansatz wie beim 1010→2020 gemacht haben (gleicher Die, anderes Gehäuse) dann wärs vielleicht wieder nur ne kleine Erweiterung in libfprint. Drücke die Daumen das der MR bald gemergt wird, dann ist die Hürde für sowas viel niedriger.