$ rust-fp match
Ready to match...
Output: NoMatch(Some(Other))
No match
Error matching: Other
I am sure I am missing something, so I am going over the process again, to make sure I haven’t. There are some differences in the file paths, of course but that is straightforward to figure out.
Can you also run sudo ectool console --name=cros_fp after NoMatch(Some(Other)) happens? Can you also run sudo ectool uptimeinfo --name=cros_fp?
NoMatch(Some(Other)) means that there was an error matching, and the error is Other
#[derive(Debug)]
pub enum EcMkbpEventFingerprintNoMatchError {
/// `EC_MKBP_FP_ERR_MATCH_NO_INTERNAL` - Probably means there was an internal error.
Internal,
/// `EC_MKBP_FP_ERR_MATCH_NO_TEMPLATES` - This either means there are no templates, or something's wrong with the templates. Idk which one.
Templates,
/// `EC_MKBP_FP_ERR_MATCH_NO_LOW_QUALITY` - My guess is this might happen if the sensor or finger is dirty
LowQuality,
/// `EC_MKBP_FP_ERR_MATCH_NO_LOW_COVERAGE` - My guess is this might happen if only a small part of a finger is sensed
LowCoverage,
}
It’s not a LowQuality error. My guess is that it is a Templates error, which probably means that no templates were uploaded to the FP sensor, which shouldn’t happen.
That’s interesting. It seems like for your Chromebook the FP sensor does not reboot when it is suspended. On my jinlon the FP sensor reboots every time it the Chromebook suspends.
@claydoh one more time when you get this error can you please send the output of: systemctl status of the dbus-interface sudo ectool --name=cros_fp console sudo ectool --name=cros_fp fpinfo sudo ectool --name=cros_fp fpstats sudo ectool --name=cros_fp uptimeinfo
I am currently implementing the missing features (saving and loading of prints) from the libfrpint PR on my github.
I implemented the downloading and saving of prints, and I am in the process of implementing the uploading of the prints.
But I am having issues if I follow the steps described by @ChocolateLoverRaj to save and upload prints. The uploaded prints do not work. (not in with my libfrpint implementation and not if I do it manually with the ectool)
If I follow the commands, I am able to enroll a print and save it (the save file is not empty).
I am also able to match a freshly enrolled print.
But if I reset and reupload the print, I cannot match it successfully.
In fact, as soon as one uploaded print is present on the sensor, matching stops working for all prints, even freshly enrolled ones, that worked directly before the upload command.
I tried both the c and rust versions of the ectool and all combinations for up and downloading.
I am also always setting the seed.
Does anybody know what my issue is? @ChocolateLoverRaj, did you have similar issues with your driver, and if yes, how did you solve it?
I did not have issues on jinlon. It issue you are getting might be Chromebook specific. I will try on a redrix soon. One thing that you may have to do in libfprint is set delays between FP commands in general. I don’t remember exactly which places, but I think I have coded delays after setting the seed and between uploading templates in rust-fp.
Also @Xelef2000 are you the same person who opened the merge request on libfprint GitLab?
Thanks for the answer.
I was hoping you knew the solution since your driver worked flawlessly when I tried it. ( I am also using a jinlon)
I will have to study your code then
And I am not the person who opened the original PR.
I will try to complete the driver and then coordinate with the project to upstream it.
I tested the rust-fp driver again, and the uploading of prints doesn’t work (anymore?), meaning that prints no longer work after a reboot, even though fpinfon reports it as uploaded.
I can’t remember if I tested it when I first tried the driver a couple of months ago.
I may have broken the reader during driver development, but I probably need to reinstall chromeos to confirm that.
It isn’t kernel related, I tried all supported versions back to 5.14 and even reverted my nix flake to the time I first tested the rust-fp driver.
@ChocolateLoverRaj
Since you are also using a Jinlon, could you share your firmware version? Maybe there was a regression there.
