Protocol error with 138a:0097 on Arch Linux
tblancher opened this issue · 7 comments
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:
fprintd-enroll -f right-index-finger
Using device /net/reactivated/Fprint/Device/0
failed to claim device: Open failed with error: The driver encountered a protocol error with the device.
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:
Sep 26 16:38:09 ferrum systemd[1]: Starting Fingerprint Authentication Daemon...
Sep 26 16:38:10 ferrum systemd[1]: Started Fingerprint Authentication Daemon.
Sep 26 16:38:10 ferrum fprintd[24570]: Expected len: 84, but got 108
Sep 26 16:38:10 ferrum fprintd[24570]: 0000 00 00 01 00 01 00 08 00 dd a6 4e 57 01 00 34 46 | ..........NW..4F
Sep 26 16:38:10 ferrum fprintd[24570]: 0010 02 00 07 00 60 39 00 00 01 00 84 08 01 00 07 00 | ....`9..........
Sep 26 16:38:10 ferrum fprintd[24570]: 0020 00 04 00 00 02 00 84 28 03 00 12 00 e0 10 00 00 | .......(........
Sep 26 16:38:10 ferrum fprintd[24570]: 0030 02 00 76 36 01 00 0c 00 10 0a 00 00 01 00 86 47 | ..v6...........G
Sep 26 16:38:10 ferrum fprintd[24570]: 0040 00 00 01 00 50 5a 00 00 02 00 23 77 00 00 01 00 | ....PZ....#w....
Sep 26 16:38:10 ferrum fprintd[24570]: 0050 80 2f 00 00 02 00 66 37 01 00 0c 00 f0 22 02 00 | ./....f7....."..
Sep 26 16:38:10 ferrum fprintd[24570]: Data exchange failed at state 3, usb error: The driver encountered a protocol error with the device.
Sep 26 16:38:10 ferrum fprintd[24570]: g_task_return_error: assertion 'G_IS_TASK (task)' failed
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:
Sep 26 17:13:36 ferrum systemd[1]: Starting Fingerprint Authentication Daemon...
Sep 26 17:13:37 ferrum systemd[1]: Started Fingerprint Authentication Daemon.
Sep 26 17:13:37 ferrum fprintd[70757]: Expected len: 84, but got 108
Sep 26 17:13:37 ferrum fprintd[70757]: 0000 00 00 01 00 01 00 08 00 dd a6 4e 57 01 00 34 46 | ..........NW..4F
Sep 26 17:13:37 ferrum fprintd[70757]: 0010 02 00 07 00 60 39 00 00 01 00 84 08 01 00 07 00 | ....`9..........
Sep 26 17:13:37 ferrum fprintd[70757]: 0020 00 04 00 00 02 00 84 28 03 00 12 00 e0 10 00 00 | .......(........
Sep 26 17:13:37 ferrum fprintd[70757]: 0030 02 00 76 36 01 00 0c 00 10 0a 00 00 01 00 86 47 | ..v6...........G
Sep 26 17:13:37 ferrum fprintd[70757]: 0040 00 00 01 00 50 5a 00 00 02 00 23 77 00 00 01 00 | ....PZ....#w....
Sep 26 17:13:37 ferrum fprintd[70757]: 0050 80 2f 00 00 02 00 66 37 01 00 0c 00 f0 22 02 00 | ./....f7....."..
Sep 26 17:13:37 ferrum fprintd[70757]: Data exchange failed at state 3, usb error: The driver encountered a protocol error with the device.
Sep 26 17:13:37 ferrum fprintd[70757]: g_task_return_error: assertion 'G_IS_TASK (task)' failed
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 108
So 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.
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.
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?
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.
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.
@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 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/libfprintWhat 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).
@piotrekzurek thanks your method worked on linuxmint 20, though in my case the links(ln -s) was not optional.