Bug 504399

Summary: Upek Fingerprint Reader TCRD4C isn't working
Product: [Fedora] Fedora Reporter: Brian C. Lane <bcl>
Component: libfprintAssignee: Bastien Nocera <bnocera>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: bnocera, czhang, daaugusto, d-bugzilla, dhollis, drepper.fsp, jan.klepek, johnp, lihamakaroonilaatikko, pingou, redhat-bugzilla, rubin, s.a.hartsuiker, sascha, sstein, vadgamaharsh, vemcontact, walicki, yo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: fprintd-0.2.0-1.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 961931 (view as bug list) Environment:
Last Closed: 2010-08-31 23:26:34 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Relevant part of output from lshal
none
Spec updates to enable support for 147e:2016 next generation
none
0001-Add-some-corrective-action-if-there-are-missing-pack.bin
none
0001-Fix-a-segfault-that-occured-if-a-scan-was-shorter-th-0001.bin
none
0002-Make-the-2-right-shift-correction-happen-on-image-ha.bin
none
0001-Dont-consider-the-scan-complete-unless-there-is-atle.bin
none
0002-upexonly.c-Fix-a-vertical-distortion-in-image-data.bin
none
This patch disables the compilation of the upeksonly driver
none
The upeke2 driver that supports the TCRD4C
none
Left out the part nuking the id's in the upeksonly driver
none
Revised patch to address upeke2 driver
none
Revised patch to address addition of upeke2 driver
none
usbdev dump on Lenovo x201
none
lsub dump on x201
none
0001-Rework-discover-code-for-drivers.patch
none
0002-Implement-discover-methods-for-upeke2-and-upeksonly.patch none

Description Brian C. Lane 2009-06-06 02:03:34 EDT
Description of problem:
I have an eikon fingerprint reader that identifies itself in lsusb as:

Bus 002 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor

When using the Gnome About dialog to set it up it doesn't recognize the finger touch.

When using fprintd-enroll it returns this error:

[bcl@lister /]$ fprintd-enroll 
Using device /net/reactivated/Fprint/Device/0
Enrolling right index finger.
Enroll result: enroll-unknown-error


Version-Release number of selected component (if applicable):
fprintd-pam-0.1-9.git04fd09cfa.fc11.i586
libfprint-0.1.0-6.pre1.fc11.i586
fprintd-0.1-9.git04fd09cfa.fc11.i586
gdm-plugin-fingerprint-2.26.1-10.fc11.i586

How reproducible:

Always
Comment 1 Brian C. Lane 2009-06-06 02:06:12 EDT
Created attachment 346743 [details]
Relevant part of output from lshal
Comment 2 Bastien Nocera 2009-06-06 07:10:45 EDT
Most likely a duplicate of bug 500460. Any chance you could test the patch there (or at least provide debug output for fprintd to assert that this is the problem)?
Comment 3 Brian C. Lane 2009-06-06 09:44:10 EDT
I'll give it a try when the mirrors become available (I don't have all the dev tools installed right now). I don't think it is the same error though, I don't see those errors logged to either dmesg or /var/log/messages.

How do I switch on debug output for fprintd? It dosn't have a manpage.
Comment 4 Bastien Nocera 2009-06-06 10:00:28 EDT
(In reply to comment #3)
> I'll give it a try when the mirrors become available (I don't have all the dev
> tools installed right now). I don't think it is the same error though, I don't
> see those errors logged to either dmesg or /var/log/messages.

Those errors aren't logged to /var/log/messages

> How do I switch on debug output for fprintd? It dosn't have a manpage.  

as root:
killall fprintd
/usr/libexec/fprintd -t

And use it.
Comment 5 Brian C. Lane 2009-06-25 01:24:29 EDT
Sorry it took so long. Output from fprintd -t while user bcl tries running fprintd-enroll (same as the output when root tries to run fprintd-enroll)


[root@lister ~]# /usr/libexec/fprintd -t
Launching FprintObject
** Message: D-Bus service launched with name: net.reactivated.Fprint
** Message: entering main loop
** Message: user 'bcl' claiming the device: 0
** Message: now monitoring fd 7
** Message: device 0 claim status 0
** Message: start enrollment device 0 finger 7
** Message: enroll_stage_cb: result -4
** Message: no longer monitoring fd 7
** Message: released device 0
Comment 6 Brian C. Lane 2009-06-25 01:37:54 EDT
I just tried libfprint-0.1.0-7.pre2.fc11.1.i586.rpm and it does not fox my problem.
Comment 7 Jan Klepek 2009-09-29 13:35:41 EDT
libfprint-0.1.0-7.pre2 doesn't work for me too (lenovo t400s)
Comment 8 Rubin Simons 2009-11-03 12:17:30 EST
I can also confirm that this does not work on my T400s. Exact same errors/behaviour as reporter.

There are posts to be found which state that 147e:2016 is working using upeksonly:

http://www.reactivated.net/weblog/archives/2008/07/upek-touchstrip-sensor-only-147e2016-on-linux/

I'm not sure if the above is a newer version of fprint or if the device found in my T400s is lying about what it really is (read: NOT a upek-touchstrip-sensor-only). I have found no other reports of people getting this usb device id on a T400s working under linux.
Comment 9 Sascha Harusta 2010-02-18 06:45:51 EST
The issue is still valid for Fedora 12
Comment 10 John (J5) Palmieri 2010-04-04 16:23:47 EDT
This is also an issue with F13 Alpha.  According to libfprint's wiki, these devices are not supported:

http://reactivated.net/fprint/wiki/Unsupported_devices#UPEK_TCRD4C_.28newer_Eikon.29

Not sure if they are working on fixing this but it would be nice to get info on upstream as to what the issue is and if anyone with these devices can help to get it working.
Comment 11 Brian Lane 2010-04-04 22:48:18 EDT
My understanding from reading the manufacturer's website and the fprint wiki is that these are closed devices and the manufacturer won't reveal anything without a NDA.
Comment 12 Jorge 2010-04-25 11:35:04 EDT
I've managed to get this device working by modifying the upekts driver. I still need some advice on how to proceed for now on, because this device has the same IS as the one supported by upeksonly, and that's a problem. Please take a look at http://lists.reactivated.net/pipermail/fprint/2010-April/001447.html
Comment 13 Jorge 2010-04-25 11:35:55 EDT
I mean "the same ID", not "the same IS", sorry by double posting!
Comment 14 Bug Zapper 2010-04-27 10:40:41 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 vadi01 2010-05-08 12:32:01 EDT
Fedora 13rc2 same issue

[root@localhost sanu01]# /usr/libexec/fprintd -t
Launching FprintObject
** Message: D-Bus service launched with name: net.reactivated.Fprint
** Message: entering main loop
** Message: user 'sanu01' claiming the device: 0
** Message: now monitoring fd 10
** Message: device 0 claim status 0
** Message: start enrollment device 0 finger 7
** Message: enroll_stage_cb: result -4
** Message: no longer monitoring fd 10
** Message: released device 0
Comment 16 Ulrich Drepper 2010-06-23 13:26:14 EDT
I have the same chip in very recent hardware (i.e., this chip remains important).

Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor


With Fedora 13 (up-to-date) for me fprintd fails fataly very early


/usr/libexec/fprintd -t
Launching FprintObject

** ERROR **: Got result code 2 from requesting name
aborting...


I've updated the version number in this bug to 13.  I'll try to use the patch in comment 12.
Comment 17 David Hollis 2010-06-23 14:27:16 EDT
I've gotten this chip working on my T410 using the various patches that have floated around the mailing list.  I'll post the diff to the SPEC as well as the patches.  One big caveat, the newer chip shares the same ID as the prior generation, though they operate quite differently.  My current .spec disables the compilation of the older device, effectively killing any support for it.  It works fairly well for me though occasionally it won't recognize the print and I have to enter a password.
Comment 18 David Hollis 2010-06-23 14:28:24 EDT
Created attachment 426345 [details]
Spec updates to enable support for 147e:2016 next generation
Comment 19 David Hollis 2010-06-23 14:30:02 EDT
Created attachment 426346 [details]
0001-Add-some-corrective-action-if-there-are-missing-pack.bin
Comment 20 David Hollis 2010-06-23 14:30:51 EDT
Created attachment 426347 [details]
0001-Fix-a-segfault-that-occured-if-a-scan-was-shorter-th-0001.bin
Comment 21 David Hollis 2010-06-23 14:31:42 EDT
Created attachment 426348 [details]
0002-Make-the-2-right-shift-correction-happen-on-image-ha.bin
Comment 22 David Hollis 2010-06-23 14:32:19 EDT
Created attachment 426349 [details]
0001-Dont-consider-the-scan-complete-unless-there-is-atle.bin
Comment 23 David Hollis 2010-06-23 14:35:11 EDT
Created attachment 426350 [details]
0002-upexonly.c-Fix-a-vertical-distortion-in-image-data.bin
Comment 24 David Hollis 2010-06-23 14:36:11 EDT
Created attachment 426351 [details]
This patch disables the compilation of the upeksonly driver
Comment 25 David Hollis 2010-06-23 14:37:43 EDT
Created attachment 426352 [details]
The upeke2 driver that supports the TCRD4C
Comment 26 David Hollis 2010-06-23 21:21:29 EDT
Created attachment 426427 [details]
Left out the part nuking the id's in the upeksonly driver
Comment 27 Didier 2010-06-24 06:25:09 EDT
Thank you for your patches, David ; much appreciated.

"rpmbuild -ba" with the patched libfprint yields :

Patch #1 (0001-Add-udev-rules-to-set-devices-to-autosuspend.patch):
+ /usr/bin/patch -s -p1 --fuzz=0
+ /bin/cat /home/didier/rpmbuild/SOURCES/0001-Add-udev-rules-to-set-devices-to-autosuspend.patch
2 out of 2 hunks FAILED -- saving rejects to file libfprint/Makefile.am.rej
error: Bad exit status from /var/tmp/rpm-tmp.911o2U (%prep)


(this is with libfprint-0.1.0-16.pre2.fc14.src.rpm from koji, as I did not find a 0.1.0-16.pre2.fc13, and release 16.pre2 is needed for the .spec diff to succeed).
Comment 28 David Hollis 2010-06-24 08:30:20 EDT
Ahh, I had forgotten that I had to tweak that patch.  I'll attach the revised version of that now.
Comment 29 David Hollis 2010-06-24 08:30:51 EDT
Created attachment 426549 [details]
Revised patch to address upeke2 driver
Comment 30 Didier 2010-06-24 11:09:24 EDT
Patches #16 and #1 apply, but #2 doesn't :

Patch #2 (0001-Add-gdk-pixbuf-support.patch):
+ /bin/cat /home/didier/rpmbuild/SOURCES/0001-Add-gdk-pixbuf-support.patch
+ /usr/bin/patch -s -p1 --fuzz=0
1 out of 4 hunks FAILED -- saving rejects to file configure.ac.rej
error: Bad exit status from /var/tmp/rpm-tmp.ytDGBD (%prep)


$ cat configure.ac.rej
--- configure.ac
+++ configure.ac
@@ -20,7 +20,7 @@
 
 all_drivers="upekts upektc upeksonly vcom5s uru4000 fdu2000 aes1610 aes2501 aes4000"
 
-require_imagemagick='no'
+require_imaging='no'
 require_aeslib='no'
 enable_upekts='no'
 enable_upektc='no'
Comment 31 David Hollis 2010-06-24 13:09:47 EDT
Shoot, didn't realize that I had to tweak that patch as well.  Attaching the revised patch.
Comment 32 David Hollis 2010-06-24 13:10:46 EDT
Created attachment 426653 [details]
Revised patch to address addition of upeke2 driver
Comment 33 Didier 2010-06-24 16:38:00 EDT
I downloaded aes1610.c from "http://guidograzioli.fedorapeople.org/aes1610/aes1610.c", and needed to disable Patch #3 in order to rebuild successfully.

Will test tomorrow (x86_64).
Comment 34 David Hollis 2010-06-24 17:06:34 EDT
I just did a cursory glance at the differences between the aes1610.c from #33 and what is created by the patch and there only seem to be whitespace differences, so I wouldn't bother disabling patch #3 and using that external source file.
Comment 35 Didier 2010-06-25 04:39:09 EDT
Upek TCRD4C Fingerprint Reader (USB ID '147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor') confirmed working on x86_64 with current patches.

One single error message in /var/log/messages :
udevd-work[8527]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2/5-2:1.0/power/level} for writing: No such file or directory

Thanks a lot for your efforts, David !
Comment 36 Robert de Rooy 2010-07-13 15:23:16 EDT
*** Bug 549437 has been marked as a duplicate of this bug. ***
Comment 37 Jari 2010-07-29 05:47:42 EDT
I'm not RH user but I thought to report that with addition of new return code from http://www.mail-archive.com/fprint@reactivated.net/msg01426.html I was able to make the fprintd-enroll work with Lenovo X201. Without the fix I was able to verify old fingerprints but not enroll new ones from command line. Maybe this could be added to libfprint-0.1.0~pre2+upeke2driver.diff.
Comment 38 Bastien Nocera 2010-08-13 10:41:29 EDT
Sorry about the lag here. I've been mostly ignoring libfprint bugs, as upstream is pretty much dead for it.

I'll try to get in touch with the maintainer so we can move the trees for libfprint and fprintd to freedesktop (for example). Once that's done, I could work on merging the patches above, with a caveat.

We obviously can't just disable a driver for a class of devices that use to work, so we could hack looking at the DMI information to switch to the correct driver.

So I'd need a complete list of the laptops that do use this variant of the fingerprint reader chipset, and I'd need access to a laptop with the problem (I already have a Dell laptop with a "normal" UPEK chip).
Comment 39 Bastien Nocera 2010-08-17 14:22:13 EDT
*** Bug 603902 has been marked as a duplicate of this bug. ***
Comment 40 Bastien Nocera 2010-08-17 14:42:34 EDT
The patch was actually missing this line:
-all_drivers="upekts upektc upeksonly vcom5s uru4000 fdu2000 aes1610 aes2501 aes4000"
+all_drivers="upeke2 upekts upektc upeksonly vcom5s uru4000 fdu2000 aes1610 aes2501 aes4000"

To compile the upeke2 driver at all.

I've committed this one patch (actually the one in bug #603902, should be the same as in comment 32) upstream (new location to be announced on the fprint list as and when the project setup is finished), with the following caveat:
+/* FIXME: Disabled for now, as this clashes with the upeksonly driver */
+/*     { .vendor = 0x147e, .product = 0x2016 }, */

We need to find a way to reliably select the correct driver for those newer Thinkpads.
Comment 41 David Hollis 2010-08-17 15:02:44 EDT
Those two fixes were in the "nuke upeksonly" patch that was attached.  

Do you happen to have any ideas as to how we can differentiate between the two devices?  I might actually have access to both (I have piles of new T400/T410s and a bunch of T60/T61's that I think use the old driver).  

Would it something as relatively easy as differences in endpoints or something or would we likely need to actually query the device and deal with its responses?
Comment 42 Bastien Nocera 2010-08-17 17:34:43 EDT
(In reply to comment #41)
> Those two fixes were in the "nuke upeksonly" patch that was attached.  

That's what you get for mislabelling patches ;)

> Do you happen to have any ideas as to how we can differentiate between the two
> devices?  I might actually have access to both (I have piles of new T400/T410s
> and a bunch of T60/T61's that I think use the old driver).  
> 
> Would it something as relatively easy as differences in endpoints or something
> or would we likely need to actually query the device and deal with its
> responses?

My first option would be to try and see differences in endpoints, or interfaces (ID_USB_INTERFACES in udev). The worst option would to whitelist laptops through DMI.

If we had access to specs, I would probably have it query the device instead.

Could you possibly attach the output of "udevadm info --export-db" and "lsusb -vvv -d 147e:" for the 2 different machines?
Comment 43 Ulrich Drepper 2010-08-17 18:14:18 EDT
Created attachment 439231 [details]
usbdev dump on Lenovo x201
Comment 44 Ulrich Drepper 2010-08-17 18:15:35 EDT
Created attachment 439233 [details]
lsub dump on x201
Comment 45 Bastien Nocera 2010-08-17 18:46:22 EDT
(In reply to comment #43)
> Created attachment 439231 [details]
> usbdev dump on Lenovo x201

They use different revisions :)

In your udev dump:
E: PRODUCT=147e/2016/2

and in one from a System76 Pangolin laptop[1] (which has the upeksonly device, Daniel used that laptop to implement the driver):
E: PRODUCT=147e/2016/1

[1]: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/521778
Comment 46 Bastien Nocera 2010-08-17 18:47:54 EDT
Created attachment 439239 [details]
0001-Rework-discover-code-for-drivers.patch
Comment 47 Bastien Nocera 2010-08-17 18:48:24 EDT
Created attachment 439240 [details]
0002-Implement-discover-methods-for-upeke2-and-upeksonly.patch
Comment 48 Bastien Nocera 2010-08-17 18:50:31 EDT
Git tree lives at:
git://git.freedesktop.org/git/libfprint/libfprint.git

The 2 patches above enable detection of the revision of the device, and should allow the driver to accept or reject the devices.

If it doesn't work, let me know. I'm not sure about the discover functions added by the 2nd patch, and I only compile tested the first patch as well...
Comment 49 Bastien Nocera 2010-08-18 06:20:43 EDT
Tested this on a T410 remotely, and apart from a crasher when a driver couldn't be found, it's all dandy.

If there are other problems with the driver, Jorge should be able to help.

I'll build packages for Fedora as soon as the project move is done upstream.
Comment 50 David Hollis 2010-08-18 09:53:18 EDT
I have an updated RPM available at:
http://www.davehollis.com/packages/libfprint-0.1.0-1.9608abgit.fc14.src.rpm
http://www.davehollis.com/packages/libfprint.spec

Which is now using the GIT repo instead of piling on the patches.  Compile and base functionality with upeke2 tested on my T410 and all is well.
Comment 51 Ulrich Drepper 2010-08-18 20:33:31 EDT
(In reply to comment #50)
> I have an updated RPM available at:
> http://www.davehollis.com/packages/libfprint-0.1.0-1.9608abgit.fc14.src.rpm
> http://www.davehollis.com/packages/libfprint.spec

Using this version I think I don't see crashes.  The LED on the reader also comes on.  But an fprintd-enroll call doesn't succeed either.  This is a x201.  I get sometimes continuous

Enroll result: enroll-remove-and-retry


In this case the program constantly reads from a file descriptor:

poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
read(5, "l\4\1\1 \0\0\0Y\0\0\0\206\0\0\0\1\1o\0 \0\0\0/net/rea"..., 2048) = 184
read(5, 0x85b280, 2048)                 = -1 EAGAIN (Resource temporarily unavailable)



Or no output and the application does not terminate:

poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, 0) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1^C <unfinished ...>
Comment 52 Fedora Update System 2010-08-19 12:34:07 EDT
control-center-2.28.1-19.fc12,fprintd-0.2.0-1.fc12,libfprint-0.2.0-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/control-center-2.28.1-19.fc12,fprintd-0.2.0-1.fc12,libfprint-0.2.0-1.fc12
Comment 53 Fedora Update System 2010-08-19 13:03:17 EDT
control-center-2.31.6-2.fc14,fprintd-0.2.0-1.fc14,libfprint-0.2.0-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/control-center-2.31.6-2.fc14,fprintd-0.2.0-1.fc14,libfprint-0.2.0-1.fc14
Comment 54 Fedora Update System 2010-08-19 22:23:31 EDT
control-center-2.28.1-19.fc12, fprintd-0.2.0-1.fc12, libfprint-0.2.0-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update control-center fprintd libfprint'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/control-center-2.28.1-19.fc12,fprintd-0.2.0-1.fc12,libfprint-0.2.0-1.fc12
Comment 55 Fedora Update System 2010-08-23 11:44:32 EDT
libfprint-0.2.0-1.fc13,fprintd-0.2.0-1.fc13,control-center-2.30.1-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libfprint-0.2.0-1.fc13,fprintd-0.2.0-1.fc13,control-center-2.30.1-3.fc13
Comment 56 Fedora Update System 2010-08-31 23:26:27 EDT
libfprint-0.2.0-1.fc13, fprintd-0.2.0-1.fc13, control-center-2.30.1-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 57 Fedora Update System 2010-09-01 02:00:16 EDT
fprintd-0.2.0-1.fc14, libfprint-0.2.0-1.fc14, control-center-2.31.90-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.