Bug 504399
|
Description
Brian C. Lane
2009-06-06 06:03:34 UTC
Created attachment 346743 [details]
Relevant part of output from lshal
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)? 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. (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. 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 I just tried libfprint-0.1.0-7.pre2.fc11.1.i586.rpm and it does not fox my problem. libfprint-0.1.0-7.pre2 doesn't work for me too (lenovo t400s) 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. The issue is still valid for Fedora 12 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. 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. 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 I mean "the same ID", not "the same IS", sorry by double posting! 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 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 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. 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. Created attachment 426345 [details]
Spec updates to enable support for 147e:2016 next generation
Created attachment 426346 [details]
0001-Add-some-corrective-action-if-there-are-missing-pack.bin
Created attachment 426347 [details]
0001-Fix-a-segfault-that-occured-if-a-scan-was-shorter-th-0001.bin
Created attachment 426348 [details]
0002-Make-the-2-right-shift-correction-happen-on-image-ha.bin
Created attachment 426349 [details]
0001-Dont-consider-the-scan-complete-unless-there-is-atle.bin
Created attachment 426350 [details]
0002-upexonly.c-Fix-a-vertical-distortion-in-image-data.bin
Created attachment 426351 [details]
This patch disables the compilation of the upeksonly driver
Created attachment 426352 [details]
The upeke2 driver that supports the TCRD4C
Created attachment 426427 [details]
Left out the part nuking the id's in the upeksonly driver
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). Ahh, I had forgotten that I had to tweak that patch. I'll attach the revised version of that now. Created attachment 426549 [details]
Revised patch to address upeke2 driver
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' Shoot, didn't realize that I had to tweak that patch as well. Attaching the revised patch. Created attachment 426653 [details]
Revised patch to address addition of upeke2 driver
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). 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. 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 !
*** Bug 549437 has been marked as a duplicate of this bug. *** 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. 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). *** Bug 603902 has been marked as a duplicate of this bug. *** 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. 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? (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? Created attachment 439231 [details]
usbdev dump on Lenovo x201
Created attachment 439233 [details]
lsub dump on x201
(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 Created attachment 439239 [details]
0001-Rework-discover-code-for-drivers.patch
Created attachment 439240 [details]
0002-Implement-discover-methods-for-upeke2-and-upeksonly.patch
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... 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. 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. (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 ...> 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 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 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 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 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. 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. |