| Git Clone URL: | https://aur.archlinux.org/libfprint-vfs009x-git.git (read-only, click to copy) |
|---|---|
| Package Base: | libfprint-vfs009x-git |
| Description: | Library for fingerprint readers (includes libre vfs0090 and vfs0097 driver) |
| Upstream URL: | https://gitlab.archlinux.org/gugah/libfprint |
| Licenses: | LGPL-2.1-or-later |
| Groups: | fprint |
| Conflicts: | libfprint |
| Provides: | libfprint, libfprint-2.so |
| Submitter: | depau |
| Maintainer: | gugah |
| Last Packager: | gugah |
| Votes: | 16 |
| Popularity: | 0.080314 |
| First Submitted: | 2020-06-21 21:32 (UTC) |
| Last Updated: | 2025-08-13 11:37 (UTC) |
I tried both of these:
for finger in right-{thumb,index-finger}; do fprintd-enroll -f "$finger" "$USER"; done &
fprintd-enroll
they both output the same error: Using device /net/reactivated/Fprint/Device/0 Enrolling right-index-finger finger. Enroll result: enroll-stage-passed Enroll result: enroll-unknown-error
I tried using the option from the KDE Settings, still errors. This Error happens after I place the first finger it tells me to.
Version : 1.94.9.r2.g450e6ae-1 Sensor : 138a:0097
@udaemon: external match means the fingerprint doesn't store the fingerprints on the device but returns a png of the fingerprint and the host OS will decide if it is a match or not (as opposed to internal match, where the device itself stores the fingerprints and returns match/no-match to the OS). Unfortunately for the vfs0090 linux driver, only external mode is supported even when the device handles both. This means you need to: 1) reset the device from the BIOS 2) use a windows VM JUST to initialize the device (ie: install the n1cgn11w driver, share the device with the VM, check in the device manager if it shows up properly; repeat share device until device manager shows it and DO NOT enroll fingerprints in win). 3) Use fprintd-enroll to generate a match-on-host association. Check if those steps work for you. Again, I don't remember having to pass BIOS settings to my VM, but I had to repeat the "share device" option with my VM until it was properly initialized.
@gugah! sorry for my late reply! I followed your steps and have the finger print reader now set to external (which, in fact, was internal before; but that doesn't have anything to do my actual issue). Then, I've reset the fpr in bios, booted into my arch, then into my virtual win10, installed the n1cgn11w-driver and went to the login options of windows' settings. here, I wanted to set up fingerprints. after I entered my pin the dialog asked to put my finger, but then the operation was cancelled with the error that a problem occurred. the fpr doesn't even blink. in the device manager the status of the fpr is "perfectly functioning", no errors here.
I weren't able to get any further. do you have ideas?
@udaemon, interestingly enough I don't remember having to adjust the BIOS settings of my VM, even after resetting the device in the BIOS. I did have to share the device like 3 times before the VM actually recognized it. Try the following please: 1) are you using match on host or match on device? make sure that in your BIOS, under Security -> Fingerprint the option for External is enabled. For vfs0090, match-on-device is not supported. 2) the driver I link in the pinned comment is newer than the one you mentioned n1cgn11w.exe over n1cgn08w. Try n1cgn11w
@gugah, thanks for your reply! in fact, validity-sensors-tools-git doesn't work for me, either. but I have got the fp reader working several times by following the steps described here (at the bottom): https://github.com/uunicorn/python-validity/issues/129 – with a now older version of python-validity (see the date of the posts). the driver in my windows vm is 5.1.341.26 which must come from the same package you have linked here (n1cgn08w resp. 6_07f_Lenovo.xpfwext). I guess, that's the latest (?).
but as to the question of the read out time, do you have any clue where to start investigating? thanks!
@udaemon this is the right place to ask. I've never noticed issues like you mentioned, in fact, the read timeout is way too long in my case. How are you initializing the device? I've used windows VM to get the latest driver for it. tbh, I never used validity-sensors-tools-git because upstream is out of date and it downloads a older version of the firmware: https://github.com/3v1n0/python-validity/blob/master/validity-sensors-tools#L55
Hi, is anybody else here facing the issue for some time (like 2 months?) with the vfs0090 fingerprint reader, that there's really short time to swipe your finger? like less than a second between the single enroll stages/tries? as if some time-out parameter had been changed in some config. maybe it came with a new version of libfprint? I'd be glad if anybody could point me to where to start investigating/asking. thanks!
@MartinX3, good to know. I updated instructions accordingly.
@gugah
Thank you!
It showed me
$ fprintd-delete $USER
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
No fingerprints to delete on Validity VFS0090
No fingerprints to delete on Validity VFS0090
But I could now finally enroll and verify my finger again! :)
@MartinX3 no, fprint 1.94.5 depends on libfprint 1.94.9 (see https://gitlab.freedesktop.org/libfprint/fprintd/-/releases/v1.94.5)
Please try fprintd-delete $USER and fprintd-enroll again. Just in case also make sure pacman -Qi libfprint-vfs009x-git shows as version 1:1.94.9.r161.g045e8ce-1, an hour prior to the last release I tried merging https://github.com/3v1n0/libfprint-tod-vfs0090/pull/2 which is, in fact, broken.
Pinned Comments
gugah commented on 2025-07-19 21:54 (UTC) (edited on 2025-08-13 21:27 (UTC) by gugah)
I was able to merge the current libfprint release from https://gitlab.freedesktop.org/libfprint/libfprint/-/tags/v1.94.9
You may have to delete and enroll the fingerprint again after updating:
Also verify it's working with:
If you keep having any issues, reset the fingerprint device in your BIOS (under Security -> Fingerprint) and initialize it again using a Windows VM with the official driver (using USB device pass-through) or validity-sensors-tools-git.
Upstream info:
There haven't been recent updates to 3v1n0's patched libfprint nor the vfs0090 driver submodule which is also hosted in https://gitlab.freedesktop.org/3v1n0/libfprint-tod-vfs0090.
I therefore forked the official libfprint (https://gitlab.archlinux.org/gugah/libfprint) and patched it with a forked driver https://gitlab.archlinux.org/gugah/libfprint-tod-vfs0090
The new patched driver includes some fixes from 3v1n0's original one:
depau commented on 2020-07-25 16:17 (UTC) (edited on 2020-10-09 19:21 (UTC) by depau)
vfs0097 users
The package will automatically apply a patch required for the vfs0097 reader if one is found in the system at build time, it will otherwise build for vfs0090. You can force a preferred behavior by exporting
VFS0097=1or=0.If you have any issues, make sure talk about it https://gitter.im/Validity90/Lobby so it has a chance to get fixed.
GH issues have also been enabled by upstream, so make sure you check that as well: https://github.com/3v1n0/libfprint/
vfs0090 users
The driver should work as expected, but same as above for any issues.