Closed tblancher closed 4 years ago
piotrekzurek
commented
4 years ago https://gitter.im/Validity90/Lobby?at=5ef3033fb8152d34845e5356 for answer to that particular error. I've created cloned repo with amended subproject here: https://github.com/piotrekzurek/libfprint it's adding only the gitter patch. depending on distribution in use you might need to change /usr/lib64/libfprint* links to /usr/local/lib64 installed libraries after compiling and installing.
tblancher
commented
4 years ago https://gitter.im/Validity90/Lobby?at=5ef3033fb8152d34845e5356 for answer to that particular error. I've created cloned repo with amended subproject here: https://github.com/piotrekzurek/libfprint it's adding only the gitter patch. depending on distribution in use you might need to change /usr/lib64/libfprint* links to /usr/local/lib64 installed libraries after compiling and installing.
I've tried through the AUR/PKGBUILD, and cloning the git repos directly. I can't figure out how to get a source directory with the vfs0090.h file that I can actually modify and build. Can you help with detailed steps on how to achieve this? Cloning the upstream libfprint from @3v1n0 doesn't appear to have vfs0090.h, and cloning your repo doesn't appear to have everything else needed. I also have never used meson or ninja to build packages by hand, maybe I'm missing something?
tblancher
commented
4 years ago I've tried cloning the vfs0090 module, but now it looks like I'm dependent upon libfprint-2-tod-1. This is not in the AUR yet. I'm going to try installing it manually.
tblancher
commented
4 years ago I give up for now. It looks like the vfs0090 version of libfprint-2-tod-1 is extremely new (latest commit was a week ago on GitLab). I've installed libfprint-2-tod-1 from here: https://gitlab.freedesktop.org/3v1n0/libfprint/-/tree/tod
But meson on this repository fails saying the run-time dependency for libfprint-2-tod-1 is not installed. I don't know how to tell meson that it is installed (looks like it installed to /usr/lib). This is getting too complicated for me right now, these are all new build tools for me so I need extra help getting this working.
piotrekzurek
commented
4 years ago @tblancher Don't know about the Arch but I suspect it should be very similar to what Fedora provides. If this is the case you should be able to compile the version patched for device with rsp lenght of 108 from my clone: https://github.com/piotrekzurek/libfprint
What I did in Fedora is I've installed the libfprint and fprintd to install runtime dependencies (and have the fprintd serivce present). But this also includes the repo's version of libfprint.so libraries that are in /usr/lib64. The meson/ninja will install the compiled version in /usr/local/lib64 and won't touch the distro's version. Because of that it was needed to delete distro provided libfprind.so* files/links and create links in the same directory to /usr/local/lib64 versions. And as a matter of fact simply deleting the distro provided files should be enough as the system should look for libs in /usr/local/ itself.
tblancher
commented
4 years ago @tblancher Don't know about the Arch but I suspect it should be very similar to what Fedora provides. If this is the case you should be able to compile the version patched for device with rsp lenght of 108 from my clone: https://github.com/piotrekzurek/libfprint
What I did in Fedora is I've installed the libfprint and fprintd to install runtime dependencies (and have the fprintd serivce present). But this also includes the repo's version of libfprint.so libraries that are in /usr/lib64. The meson/ninja will install the compiled version in /usr/local/lib64 and won't touch the distro's version. Because of that it was needed to delete distro provided libfprind.so* files/links and create links in the same directory to /usr/local/lib64 versions. And as a matter of fact simply deleting the distro provided files should be enough as the system should look for libs in /usr/local/ itself.
Arch actually provides a command called arch-meson which sets up the right paths for the libraries when you do sudo ninja -C build install. fprintd-enroll now works for me, for all ten fingers! Thanks so much for providing your repository. For me, this can be closed. I don't know if this patch will break anyone with a 138a:0097 where the rsp_length is supposed to be 84. Is there a way to programmatically determine which length is appropriate? Maybe the patch should be accepted upstream if it can make that determination (so it doesn't break anyone).
j3ffrw
commented
3 years ago @piotrekzurek thanks your method worked on linuxmint 20, though in my case the links(ln -s) was not optional.
I have a Validity Sensors 0097:
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc.I have fprintd-1.90.1-1 installed, with libfprint-vfs009x-git-1.90.1.r3.gc6f5f0e-1 installed from the AUR. I get the following error when trying to enroll my right-index-finger:
I've already enrolled all of my fingers with validity-sensors-tools, as root. It took a few tries, with a couple of re-initiliazations, but I have all ten fingers enrolled that way.
The journal is rather telling. I see the following output every time I try fprintd-enroll:
I installed fprintd-libfprint2-1.90.1+91+g4e47222-2 from the AUR, and changed the PKGBUILD to depend on libfprint-vfs009x-git instead of libfprint, but I get the same results:
I have run this a few times, and I consistently get the following log line:
Sep 26 16:38:10 ferrum fprintd[24570]: Expected len: 84, but got 108So either something is wrong with fprintd, or there's something wrong with libfprint-vfs009x-git. I know this fingerprint sensor works, I was using it prior to getting it serviced under warranty for some failed hardware. Before I had this serviced, I had to enroll my fingerprints using a Windows 10 VM in VirtualBox. I was delighted to learn there's a pure Linux method available for my fingerprint reader. It feels so close.
EDIT: Not sure if @3v1n0 sees these. Pinging them for visibility.