Using libfprint & fprintd 0.6.0 I can enroll the fingerprints but verification always fails. libfprint 0.5.1 worked fine. See terminal output (0.6.0) below. $ fprintd-enroll zdenek Using device /net/reactivated/Fprint/Device/0 Enrolling right-index-finger finger. Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-completed $ fprintd-verify zdenek Using device /net/reactivated/Fprint/Device/0 Listing enrolled fingers: - #0: right-index-finger Verify result: verify-no-match (done) I tried many times, so it's really caused by the upgrade 0.5.1->0.6.0 Here are also two related bugs in RedHat's bugzilla. (I am running Fedora 21) https://bugzilla.redhat.com/show_bug.cgi?id=1199459 https://bugzilla.redhat.com/show_bug.cgi?id=1197972
btw, it's tested on Lenovo ThinkPad T410s: $ lsusb | grep -i finger Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
(In reply to Zdeněk Zikán from comment #1) > btw, it's tested on Lenovo ThinkPad T410s: > > $ lsusb | grep -i finger > Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip > Fingerprint Sensor Could you please recompile libfprint with debug log enabled (--enable-debug-log switch to the configure script), retry enrolling/verifying and attach log to this bug report? libfprint-0.6.0 has new imaging driver (upektc_img) for your hardware, and bz3_threshold is raised for this driver (it's 70 while other drivers has 40), due to high amount of false-matches Thanks!
Oh right. So the the thresholds were _deliberately_ increased - by 30 points! Unfortunately, whoever thought that was a good idea failed to recognise that _real_ users of computers are not blocks of silicon chained to a mainframe in a moisture-free, dust-free environment. The fingerprints of _real_ users _actually_ stretch and morph over time due to the natural flexibility of skin (wow!) and the necessity to use their fingers for other tasks such as driving (extraordinary!) or typing (amazing!) and don't always have access to 100% alcohol hand rubs (how unhygienic!).
(In reply to william.chan4 from comment #3) > Oh right. So the the thresholds were _deliberately_ increased - by 30 > points! Unfortunately, whoever thought that was a good idea failed to > recognise that _real_ users of computers are not blocks of silicon chained > to a mainframe in a moisture-free, dust-free environment. The fingerprints > of _real_ users _actually_ stretch and morph over time due to the natural > flexibility of skin (wow!) and the necessity to use their fingers for other > tasks such as driving (extraordinary!) or typing (amazing!) and don't always > have access to 100% alcohol hand rubs (how unhygienic!). Whoever wrote this comment has failed to recognize that author of this driver (btw, it's indroduced in 0.6.0, earlier versions used hardware to verify scan, but it can't compare a scan to several samples) _did_ testing and _did_ find out that match score even for non-accurate scan goes over 100 points, but for other fingers (and even other people) sometimes it goes over 40. If threshold value is left by default it means that someone can unlock your laptop with his/her finger.
(In reply to william.chan4 from comment #3) > Oh right. So the the thresholds were _deliberately_ increased - by 30 > points! Unfortunately, whoever thought that was a good idea failed to > recognise that _real_ users of computers are not blocks of silicon chained > to a mainframe in a moisture-free, dust-free environment. The fingerprints > of _real_ users _actually_ stretch and morph over time due to the natural > flexibility of skin (wow!) and the necessity to use their fingers for other > tasks such as driving (extraordinary!) or typing (amazing!) and don't always > have access to 100% alcohol hand rubs (how unhygienic!). This will be your only warning. Not taking passing aggressive BS comments.
I have an idea how to improve it. On small sensors it's necessary to find and discard points which belong to convex hull, since they're not minutiaes. That should improve match rate without increasing a threshold.
Created attachment 114318 [details] [review] 0001-nbis-add-one-more-step-of-false-minutia-removal.patch
Created attachment 114319 [details] [review] 0002-lib-add-partial-image-flag.patch
Created attachment 114320 [details] [review] 0003-upektc_img-set-partial-flag-on-an-image.patch
Please test attached patches. They should improve matching rate (at least at some extent). I've lowered bz3_threshold, since now amount of detected minutiae isn't as high as before, and match rate rarely goes above 40-70.
Created attachment 114321 [details] [review] 0001-nbis-add-one-more-step-of-false-minutia-removal.patch
Created attachment 114324 [details] [review] 0003-upektc_img-set-partial-flag-on-an-image.patch Lower bz3_threshold to 30, according to tests with latest changes, for wrong finger score never goes about 10, but for right finger it sometimes a bit below 40.
Created attachment 114325 [details] [review] 0004-aes1660-set-partial-flag-on-an-image.patch aes1660 has the same issue with sensor width.
Bastian, as far as I remember you own Thinkpad X1 with Upek sensor, could you please test at least patches 1-3? If they're OK for you I'll push them to fdo git.
Hi, I have a similar issue with an EgisTec ES603 (1c7a:0603) on 0.6.0: it never matches the verification. I recompiled with --enable-debug-log but... where is the log stored?
(In reply to Dario from comment #15) > Hi, I have a similar issue with an EgisTec ES603 (1c7a:0603) on 0.6.0: it > never matches the verification. > > I recompiled with --enable-debug-log but... where is the log stored? To stderr/stdout. Btw, this bug has 4 patches to try, that's why status is "NEEDINFO". Did you try them?
I have not tried any of the patches, but could provide a debug log, but I wonder if it does contain information to replay the fingerprint? The machine is a Lenovo X250: fp:debug [find_supporting_driver] driver vfs5011 supports USB device 138a:0017 fp:debug [find_supporting_driver] selected driver vfs5011 supports USB device 138a:0017
(In reply to Daniel Hahler from comment #17) > I have not tried any of the patches, but could provide a debug log, but I > wonder if it does contain information to replay the fingerprint? > > The machine is a Lenovo X250: > > fp:debug [find_supporting_driver] driver vfs5011 supports USB device > 138a:0017 > fp:debug [find_supporting_driver] selected driver vfs5011 supports USB > device 138a:0017 138a:0017 is Validity scanner, not Upek.
> 138a:0017 is Validity scanner, not Upek. Is this bug only about Upek then? Should/could I still try one of the patches, or are they all meant for Upek only?
(In reply to Daniel Hahler from comment #19) > > 138a:0017 is Validity scanner, not Upek. > > Is this bug only about Upek then? > > Should/could I still try one of the patches, or are they all meant for Upek > only? These patches aren't Upek-only, but they don't affect vfs5011 driver. And moreover, they're outdated. I have some fixes for vfs5011 in my github repo as well. See https://github.com/anarsoul/libfprint
> https://github.com/anarsoul/libfprint Awesome, that works now for me. I've noticed that fprint-enroll took multiple rounds now: Using device /net/reactivated/Fprint/Device/0 Enrolling right-index-finger finger. Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-stage-passed Enroll result: enroll-completed Apart from that, I would say that fprintd-verify should probably exit non-zero in case it was not verified?! But that's another issue anyway.
Some improvements were merged into libfprint git master back in January. Try them and reopen if it still fails for you.
Just tried it with libfprint-upstream-git from AUR as well as stable package in the arch repositories and I still end up with "verify-no-match" most of the time. 147e:2016 Upek Biometry Touchchip/Touchstrip Fingerprint Sensor Works just fine on windows 10. I'll attach the debug logs in a moment.
Created attachment 128865 [details] debug log of enrolling, then attempting to verify the fingerprint
(In reply to chrno-sphered from comment #23) > Just tried it with libfprint-upstream-git from AUR as well as stable package > in the arch repositories and I still end up with "verify-no-match" most of > the time. > > 147e:2016 Upek Biometry Touchchip/Touchstrip Fingerprint Sensor Try swipe finger differently (with different angles, different parts of finger) during enrollment. Btw, 2 our of 5 scans for your enrolled fingers have only 17 minutiae, that's a bit low. > Works just fine on windows 10. I'll attach the debug logs in a moment. That could be a problem. Windows driver may upload new firmware to the device, which may persist across reboots. Does libfprint work better for you on cold boot?
I only booted win10 a couple of times and fast startup is disabled, so this should be on cold boot. I've also tried moving the finger differently on another enrollment, and it doesn't really perform any better (in fact, now I can't get it to verify even once).
I've just deleted all fingerprints and installed fingerprint-gui, which also uses libfprint - scanning the same finger enrolled with it verifies 100% Looks like it's not a problem with libfprint, but fprintd?
(In reply to chrno-sphered from comment #27) > I've just deleted all fingerprints and installed fingerprint-gui, which also > uses libfprint - scanning the same finger enrolled with it verifies 100% > > Looks like it's not a problem with libfprint, but fprintd? If it uses libfprint, it probably means that you enrolled your finger better this time. Could you try to overwrite fprintd's enrolled data (it's somewhere in /var/lib/fprint/username/0011/00000000/7) with fingerprint-gui's?
Doesn't seem like they are using the same format (libfprint is a dependency though). The fingerprint data is saved in /var/lib/fingerprint-gui/<username>/libbsapi/6.bir, overwriting the file generated by fprintd results in "VerifyStart failed: No such print 7". Permissions are the same for new and old files. After that, the fingerprint device is displayed as "already claimed" and I have to reboot to get the fingerprint reader working again. I don't think it's a matter of better enrollment, though. I have now enrolled my finger 4 times with fprintd and it only works about 1 in 20 attempts. Enrolling my finger 4 times with fingerprint-gui still verifies 100%. Using the same motion each time, so I don't know.
(In reply to chrno-sphered from comment #23) > Just tried it with libfprint-upstream-git from AUR as well as stable package > in the arch repositories and I still end up with "verify-no-match" most of > the time. > > 147e:2016 Upek Biometry Touchchip/Touchstrip Fingerprint Sensor > > Works just fine on windows 10. I'll attach the debug logs in a moment. I'm going to close this, it's a year later and even if there weren't any releases during that time, there were plenty of bug fixes made in git. (In reply to chrno-sphered from comment #29) > Doesn't seem like they are using the same format (libfprint is a dependency > though). The fingerprint data is saved in > /var/lib/fingerprint-gui/<username>/libbsapi/6.bir, overwriting the file > generated by fprintd results in "VerifyStart failed: No such print 7". > Permissions are the same for new and old files. And this is using "fingerprint-gui"'s integration into proprietary drivers. We don't and won't support those.
(In reply to Bastien Nocera from comment #30) > (In reply to chrno-sphered from comment #23) > > Just tried it with libfprint-upstream-git from AUR as well as stable package > > in the arch repositories and I still end up with "verify-no-match" most of > > the time. > > > > 147e:2016 Upek Biometry Touchchip/Touchstrip Fingerprint Sensor > > > > Works just fine on windows 10. I'll attach the debug logs in a moment. > > I'm going to close this, it's a year later and even if there weren't any > releases during that time, there were plenty of bug fixes made in git. I fail to understand that reasoning. Obviously, even with all the fixes since the bug was filed, there are still problems getting the fingerprint verified, _using current libfprint-git snapshot_. Would you like me to create a duplicate report instead? > (In reply to chrno-sphered from comment #29) > > Doesn't seem like they are using the same format (libfprint is a dependency > > though). The fingerprint data is saved in > > /var/lib/fingerprint-gui/<username>/libbsapi/6.bir, overwriting the file > > generated by fprintd results in "VerifyStart failed: No such print 7". > > Permissions are the same for new and old files. > > And this is using "fingerprint-gui"'s integration into proprietary drivers. > We don't and won't support those. The point was that it works with another program allegedly using libfprint, it wasn't a request to support whatever fingerprint-gui does.
(In reply to chrno-sphered from comment #31) > (In reply to Bastien Nocera from comment #30) > > (In reply to chrno-sphered from comment #23) > > > Just tried it with libfprint-upstream-git from AUR as well as stable package > > > in the arch repositories and I still end up with "verify-no-match" most of > > > the time. > > > > > > 147e:2016 Upek Biometry Touchchip/Touchstrip Fingerprint Sensor > > > > > > Works just fine on windows 10. I'll attach the debug logs in a moment. > > > > I'm going to close this, it's a year later and even if there weren't any > > releases during that time, there were plenty of bug fixes made in git. > I fail to understand that reasoning. Obviously, even with all the fixes > since the bug was filed, there are still problems getting the fingerprint > verified, _using current libfprint-git snapshot_. Would you like me to > create a duplicate report instead? Yes please. We're already 30 comments into this, and a number of changes have been made in response to this bug. The changes were also committed for quite a while, so a new bug is fine. Make a reference to this bug in the new one if you feel that it's the same problem. > > (In reply to chrno-sphered from comment #29) > > > Doesn't seem like they are using the same format (libfprint is a dependency > > > though). The fingerprint data is saved in > > > /var/lib/fingerprint-gui/<username>/libbsapi/6.bir, overwriting the file > > > generated by fprintd results in "VerifyStart failed: No such print 7". > > > Permissions are the same for new and old files. > > > > And this is using "fingerprint-gui"'s integration into proprietary drivers. > > We don't and won't support those. > The point was that it works with another program allegedly using libfprint, > it wasn't a request to support whatever fingerprint-gui does. Right. That points to the hardware working, as a data point.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.