Arch Linux User Repository

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:

fprintd-delete $USER
fprintd-enroll

Also verify it's working with:

fprintd-verify

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:

• https://github.com/3v1n0/libfprint-tod-vfs0090/compare/master...Shade30:libfprint-tod-vfs0090:master (credits to svfedorov)
• https://gitlab.freedesktop.org/3v1n0/libfprint-tod-vfs0090/-/merge_requests/2/diffs (credits to valodim)
• https://gitlab.archlinux.org/gugah/libfprint-tod-vfs0090/-/merge_requests/1/diffs

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=1 or =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.

I am on vfs0097 and also have the problem that enrolling doesn't work, I get

Enroll result: enroll-stage-passed 
Enroll result: enroll-unknown-error

On the second request for fingerprint, the control light on the fp reader blinks red.

From journalctl:

Feb 16 17:29:42 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:42 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:42 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:45 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:45 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:45 thinktux fprintd[8927]: Reply mismatch, expected at char 6 (actual 0xd, expected  0x2)
Feb 16 17:29:47 thinktux fprintd[8927]: Device reported an error during enroll: This device currently only supports enrolling fingers that have been previously enrolled using external tools, use validity-sens>

fprintd version: 1.94.5-1
libfprint-vfs009x-git version: 1.94.9.r2.g450e6ae

What I did:

- Reset fp reader in BIOS
- Boot Win 10 in Virtualbox, install latest driver, connect the fp reader: it took 3 attempts to connect, after that the device appeared in the device manager of win 10
- Close VM and Virtualbox
- sudo frintd-delete <my-username>
- sudo fprintd-enroll

Reading the comments here, I'm not sure if it is actually possible to get this working with vfs0097, is it?

@gugah NEWS (https://gitlab.archlinux.org/gugah/libfprint/-/blob/vfs009x/NEWS?ref_type=heads) shows

2025-02-20: v1.94.9 release

Highlights: * uru4000: Use OpenSSL to perform AES-ECB encryption, as per this libfprint does not support on NSS, but on openssl (>= 3.0).

Is openssl-1.1 still a dependency there?

I installed these yay packages, and it seems to be working fine now validity-sensors-tools-git, python-validity, open-fprintd, fprintd-clients-git

@esq: I don't have the 138a:0097 to test the device on this driver. But... looking at the original author's code (https://gitlab.freedesktop.org/3v1n0/libfprint-tod-vfs0090/-/commit/80423c810c8e00a4929d6973b247a04354d8d136), the patch applied to this code is insufficient. I'll try to amend 0001-VFS0097-Update-vfs0090.h.patch and report back

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