Bug 474994 - no support for Upek Touchstrip (147e:1000)
no support for Upek Touchstrip (147e:1000)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libfprint (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 538438
  Show dependency treegraph
 
Reported: 2008-12-06 08:42 EST by Khashayar Naderehvandi
Modified: 2010-12-04 19:38 EST (History)
13 users (show)

See Also:
Fixed In Version: libfprint-0.3.0-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 538438 (view as bug list)
Environment:
Last Closed: 2010-12-04 19:38:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 301567 None None None Never

  None (edit)
Description Khashayar Naderehvandi 2008-12-06 08:42:16 EST
Description of problem:
There is currently no support for the Upek Touchstrip 147e:1000. Relevant output of lsusb follows below. 

Version-Release number of selected component (if applicable):
0.0.5-6.fc10, but this bug applies, as far as I know, to all versions of libfprint. There simply is no support for this device yet.


Additional info:
Output of lsusb

Bus 003 Device 004: ID 147e:1000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x147e 
  idProduct          0x1000 
  bcdDevice            0.33
  iManufacturer           1 TouchStrip        
  iProduct                2 Fingerprint Sensor   
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)
Comment 1 Bastien Nocera 2008-12-17 09:17:30 EST
In which piece of hardware did you find this device?
Comment 2 Khashayar Naderehvandi 2008-12-17 14:58:12 EST
Oh, sorry about that.
It's in an Asus N20A notebook.

Please let me know if I can help out in any way possible.
Comment 3 Khashayar Naderehvandi 2009-01-11 08:25:47 EST
Some more info [1]:
It's a touchstrip fingerprint reader UPEK TCS4 family
Device build in:
Vaio BZ Series
Vaio SR Series
Vaio Z Series
Compal JLH 90
Thinkpad SL 300 & 500
Asus N10-XXXX
And probably many other laptops.


UPEK has released a proprietary blob for linux that works fine for this device. The fingerprintGUI [2] application, bundles and optionally uses said blob to enable the scanner under linux. With the blob enabled, I have used usbmon to do some sniffing, following the instructions available on the libfprint wiki. If Redhat engineers have any plans to start reverse engineering this device, please let me know and I'll attach the logs.


[1] copied from https://bugs.launchpad.net/ubuntu/+bug/301567/comments/1
[2] http://www.n-view.net/Appliance/fingerprint/
Comment 4 Bastien Nocera 2009-05-19 11:57:13 EDT
This seems to be 2 different fingerprint readers you're talking about.

The one you mentioned in comment 0 would use the "upekts" driver, the one in comment 3 would be using "upektc".

In the libfprint sources, you'll need to try and see which driver would support your device by adding the line:
{ .vendor = 0x147e, .product = 0x1000 },
in the "id_table" structure.

You'll need to try either libfprint/drivers/upekts.c, or libfprint/drivers/upektc.c, and see which one works.

Let me know if any of those works.
Comment 5 Khashayar Naderehvandi 2009-05-19 12:21:50 EDT
Unfortunately, I don't have much time nowadays to tinker.

But, if I understand you correctly, you mean that the source code for the 147e:1000 device might already be there, the device ID only needs to be added for everything to work?

If that's the case, I'd send an email to the libfprint list explaining that, as I've seen a couple of other people lurking around there hoping for supported 147e:1000 devices.

Also, I'm not sure how the fingerprint scanner in comment 0 and comment 3 are different? I thought they would be the same, since they share the same vendor and product ID. In either case, my device is the one in comment 0.
Comment 6 Luiz Angelo Daros de Luca 2009-05-23 15:18:46 EDT
Hello Bastien,

I tested with upekts, upektc and upeksonly (adding vendor/product id). Maybe the last one is a better guess as it has the same vendor_id.
None of them worked. I just managed to use the fingerprint reader with BSAPI.so from vendor but not with fprint(git).
When I tested with fprint upeksonly, it set some invalid state in my fingerprint reader that BSAPI just works again after a cold boot. Simple reboot does not solve.

My tests (all with root):

1) Open Fingerprint-GUI (with BSPAI): worked

2) Use upekts: failed on example/enroll

This program will enroll your right index finger, unconditionally overwriting any right-index print that was enrolled previously. If you want to continue, press enter, otherwise hit Ctrl+C                                                                                            

fp:debug [fp_init] 
fp:debug [register_driver] registered driver upekts
fp:debug [register_driver] registered driver aes4000
fp:debug [register_driver] registered driver aes2501
fp:debug [register_driver] registered driver uru4000
fp:debug [register_driver] registered driver vcom5s 
fp:debug [register_driver] registered driver upeksonly
fp:debug [find_supporting_driver] driver upekts supports USB device 147e:1000
Found device claimed by UPEK TouchStrip driver                               
sync:debug [fp_dev_open]                                                     
async:debug [fp_async_dev_open]                                              
async:debug [fpi_drvcb_open_complete] status 0                               
sync:debug [sync_open_cb] status 0
Opened device. It's now time to enroll your finger.

You will need to successfully scan your finger 3 times to complete the process.

Scan your finger now.
sync:debug [fp_enroll_finger_img]
async:debug [fp_async_enroll_start] starting enrollment
drv:debug [__ssm_call_handler] 0x604540 entering state 0
drv:debug [__ssm_call_handler] 0x604580 entering state 0
sync:debug [fp_enroll_finger_img] upekts will handle enroll stage 0/2
drv:debug [__ssm_call_handler] 0x604580 entering state 1
upekts:error [read_msg_cb] async msg read failed, code 2
drv:debug [fpi_ssm_mark_aborted] error -1 from state 1
drv:debug [fpi_ssm_mark_completed] 0x604580 completed with status -1
drv:debug [fpi_ssm_mark_aborted] error -1 from state 0
drv:debug [fpi_ssm_mark_completed] 0x604540 completed with status -1
async:debug [fpi_drvcb_enroll_started] status -1
sync:debug [sync_enroll_cb] result -1
sync:error [fp_enroll_finger_img] unrecognised return code -1
sync:debug [fp_enroll_finger_img] ending enrollment
async:debug [fp_async_enroll_stop]
drv:debug [__ssm_call_handler] 0x604540 entering state 0
upekts:debug [alloc_send_cmdresponse_transfer] seq=07 len=1
drv:debug [__ssm_call_handler] 0x604540 entering state 1
upekts:error [read_msg_cb] async msg read failed, code 2
drv:debug [fpi_ssm_mark_aborted] error -1 from state 1
drv:debug [fpi_ssm_mark_completed] 0x604540 completed with status -1
async:debug [fpi_drvcb_enroll_stopped]
sync:debug [enroll_stop_cb]
Enroll failed with error -22
sync:debug [fp_dev_close]
async:debug [fpi_drvcb_close_complete]
sync:debug [sync_close_cb]
fp:debug [fp_exit]

3) Open Fingerprint-GUI (with BSPAI): worked 

4) Use upektc: not built (why?) 

There is just this entry in Makefile
UPEKTC_SRC = drivers/upektc.c 
And no upektc related lib in .libs

5) use upeksonly

LD_LIBRARY_PATH=libfprint/.libs/ examples/enroll                                
This program will enroll your right index finger, unconditionally overwriting any right-index print that was enrolled previously. If you want to continue, press enter, otherwise hit Ctrl+C                                                                                            

fp:debug [fp_init] 
fp:debug [register_driver] registered driver upekts
fp:debug [register_driver] registered driver aes4000
fp:debug [register_driver] registered driver aes2501
fp:debug [register_driver] registered driver uru4000
fp:debug [register_driver] registered driver vcom5s 
fp:debug [register_driver] registered driver upeksonly
fp:debug [find_supporting_driver] driver upeksonly supports USB device 147e:1000
Found device claimed by UPEK TouchStrip Sensor-Only driver                      
sync:debug [fp_dev_open]                                                        
async:debug [fp_async_dev_open]                                                 
async:debug [fpi_drvcb_open_complete] status 0                                  
sync:debug [sync_open_cb] status 0                                              
Opened device. It's now time to enroll your finger.                             

You will need to successfully scan your finger 1 times to complete the process.

Scan your finger now.
sync:debug [fp_enroll_finger_img] 
async:debug [fp_async_enroll_start] starting enrollment
fp:debug [generic_acquire_start] action 1              
drv:debug [__ssm_call_handler] 0x605940 entering state 0
upeksonly:debug [write_regs_iterate] set 49=00          
sync:debug [fp_enroll_finger_img] upeksonly will handle enroll stage 0/0
upeksonly:debug [write_regs_iterate] set 3e=83                          
upeksonly:debug [write_regs_iterate] set 3e=4f                          
upeksonly:debug [write_regs_iterate] set 3e=0f                          
upeksonly:debug [write_regs_iterate] set 3e=bf                          
upeksonly:debug [write_regs_iterate] set 3e=45                          
upeksonly:debug [write_regs_iterate] set 3e=35                          
upeksonly:debug [write_regs_iterate] set 3e=1c                          
upeksonly:debug [write_regs_iterate] set 3e=ae                          
upeksonly:debug [write_regs_iterate] set 44=01                          
upeksonly:debug [write_regs_iterate] set 43=06                          
upeksonly:debug [write_regs_iterate] set 43=05                          
upeksonly:debug [write_regs_iterate] set 43=04                          
upeksonly:debug [write_regs_iterate] set 44=00                          
upeksonly:debug [write_regs_iterate] set 0b=00                          
drv:debug [__ssm_call_handler] 0x605940 entering state 1                
upeksonly:debug [sm_read_reg] read reg 09                               
upeksonly:debug [sm_read_reg_cb] read reg result = 20                   
drv:debug [__ssm_call_handler] 0x605940 entering state 2                
upeksonly:debug [sm_write_reg] set 09=20                                
drv:debug [__ssm_call_handler] 0x605940 entering state 3                
upeksonly:debug [sm_read_reg] read reg 13                               
upeksonly:debug [sm_read_reg_cb] read reg result = 45                   
drv:debug [__ssm_call_handler] 0x605940 entering state 4                
upeksonly:debug [sm_write_reg] set 13=45                                
drv:debug [__ssm_call_handler] 0x605940 entering state 5                
upeksonly:debug [sm_write_reg] set 04=00                                
drv:debug [__ssm_call_handler] 0x605940 entering state 6                
upeksonly:debug [sm_write_reg] set 05=00                                
drv:debug [fpi_ssm_mark_completed] 0x605940 completed with status 0     
fp:debug [fpi_imgdev_activate_complete] status 0                        
async:debug [fpi_drvcb_enroll_started] status 0                         
drv:debug [__ssm_call_handler] 0x61e1b0 entering state 0                
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 0                
upeksonly:debug [write_regs_iterate] set 0a=00                          
upeksonly:debug [write_regs_iterate] set 0a=00                          
upeksonly:debug [write_regs_iterate] set 09=20                          
upeksonly:debug [write_regs_iterate] set 03=3b                          
upeksonly:debug [write_regs_iterate] set 00=67                          
upeksonly:debug [write_regs_iterate] set 00=67                          
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 1                
upeksonly:debug [sm_read_reg] read reg 01                               
upeksonly:debug [sm_read_reg_cb] read reg result = ee                   
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 2                
upeksonly:debug [sm_write_reg] set 01=46                                
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 3                
upeksonly:debug [write_regs_iterate] set 01=c6                          
upeksonly:debug [write_regs_iterate] set 0c=13                          
upeksonly:debug [write_regs_iterate] set 0d=0d                          
upeksonly:debug [write_regs_iterate] set 0e=0e                          
upeksonly:debug [write_regs_iterate] set 0f=0d                          
upeksonly:debug [write_regs_iterate] set 0b=00                          
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 4                
upeksonly:debug [sm_read_reg] read reg 13                               
upeksonly:debug [sm_read_reg_cb] read reg result = 45                   
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 5                
upeksonly:debug [sm_write_reg] set 13=45                                
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 6                
upeksonly:debug [write_regs_iterate] set 13=45                          
upeksonly:debug [write_regs_iterate] set 30=e0                          
upeksonly:debug [write_regs_iterate] set 12=01                          
upeksonly:debug [write_regs_iterate] set 20=01                          
upeksonly:debug [write_regs_iterate] set 09=20                          
upeksonly:debug [write_regs_iterate] set 0a=00                          
upeksonly:debug [write_regs_iterate] set 30=e0                          
upeksonly:debug [write_regs_iterate] set 20=01                          
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 7                
upeksonly:debug [sm_read_reg] read reg 07                               
upeksonly:debug [sm_read_reg_cb] read reg result = 10                   
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 8                
upeksonly:debug [sm_write_reg] set 07=10                                
drv:debug [__ssm_call_handler] 0x61e0f0 entering state 9                
upeksonly:debug [write_regs_iterate] set 08=00                          
upeksonly:debug [write_regs_iterate] set 10=00                          
upeksonly:debug [write_regs_iterate] set 12=01                          
upeksonly:debug [write_regs_iterate] set 11=bf                          
upeksonly:debug [write_regs_iterate] set 12=01                          
upeksonly:debug [write_regs_iterate] set 07=10                          
upeksonly:debug [write_regs_iterate] set 07=10                          
upeksonly:debug [write_regs_iterate] set 04=00                          
upeksonly:debug [write_regs_iterate] set 05=00                          
upeksonly:debug [write_regs_iterate] set 0b=00                          
upeksonly:debug [write_regs_iterate] set 15=20                          
upeksonly:debug [write_regs_iterate] set 30=e1                          
upeksonly:debug [write_regs_iterate] set 15=24
upeksonly:debug [write_regs_iterate] set 15=04
upeksonly:debug [write_regs_iterate] set 15=84
drv:debug [fpi_ssm_mark_completed] 0x61e0f0 completed with status 0
drv:debug [__ssm_call_handler] 0x61e1b0 entering state 1
upeksonly:debug [sm_await_intr]
upeksonly:debug [sm_await_intr_cb] interrupt received: 01 00 00 00
fp:debug [fpi_imgdev_report_finger_status] finger on sensor
drv:debug [__ssm_call_handler] 0x61e1b0 entering state 2
drv:debug [__ssm_call_handler] 0x61e130 entering state 0
drv:debug [__ssm_call_handler] 0x61e130 entering state 1
upeksonly:debug [sm_write_reg] set 15=20
drv:debug [__ssm_call_handler] 0x61e130 entering state 2
upeksonly:debug [sm_write_reg] set 30=e0
drv:debug [__ssm_call_handler] 0x61e130 entering state 3
drv:debug [__ssm_call_handler] 0x61e130 entering state 4
upeksonly:debug [write_regs_iterate] set 09=28
upeksonly:debug [write_regs_iterate] set 13=55
upeksonly:debug [write_regs_iterate] set 0b=80
upeksonly:debug [write_regs_iterate] set 04=00
upeksonly:debug [write_regs_iterate] set 05=00
drv:debug [fpi_ssm_mark_completed] 0x61e130 completed with status 0
drv:debug [__ssm_call_handler] 0x61e1b0 entering state 3
upeksonly:debug [handle_packet] detected wraparound
upeksonly:debug [handle_packet] detected wraparound
^C to kill infinity loop

6) Open Fingerprint-GUI (with BSPAI): does not work anymore

7) poweroff/poweron

8) Open Fingerprint-GUI (with BSPAI): works again 

I captured Fingerprint-GUI working with wireshark. If it is useful, I can attach.

How can I help? Where do I start?
Comment 7 Adam Williamson 2009-09-30 15:46:39 EDT
someone's reporting this same problem in F11 on the forum:

http://forums.fedoraforum.org/showthread.php?t=231070

also found an Ubuntu thread:

https://bugs.launchpad.net/ubuntu/+bug/301567

which confirms it works if selected as an 'unknown' device in this fingerprint-gui thing.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Bruno Medeiros 2009-09-30 19:13:02 EDT
I have the same fprint device on a Dell Vostro 1520 notebook.

It's my first notebook with fprint, so I don't have experience with fprint drivers, etc.

How can I help to have support for this device?

fprint_demo tells me that 'no device is found'.
lsusb tells me 'Bus 008 Device 003: ID 147e:1000 Upek '
Comment 9 Eric Donkersloot 2009-10-05 08:12:28 EDT
This particular fingerprint reader is also present on a Sony Vaio VGN-BZ12XN.
Comment 10 Jay Turner 2009-10-20 09:39:57 EDT
I've got one in a Sony Vaio VGN-AW230J which isn't working either:

fprintd-0.1-15.git04fd09cfa.el6.x86_64
fprintd-pam-0.1-15.git04fd09cfa.el6.x86_64
libfprint-0.1.0-10.pre2.el6.x86_64
Comment 11 The Source 2009-10-26 09:40:17 EDT
Same here. ASUS N51VF
Comment 12 cervajs 2009-10-26 10:02:35 EDT
i have one in ASmobile Z97V
Comment 13 Bug Zapper 2009-11-18 05:21:54 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 14 Khashayar Naderehvandi 2009-11-18 06:28:29 EST
There's still no support for this fingerprint device, changing version to Fedora 12.
Comment 15 Black God 2010-07-22 11:50:22 EDT
The upeksonly module in libfprint package supports this. But the upeksonly.c does not list this particular VID/PID. I tried adding 1470:1000 to the supported device table of upeksonly, it works fine. No more "Unknown device". Here is how I got it? May be useful for some one.

http://karuppuswamy.com/wordpress/2010/07/22/how-to-get-fingerprint-reader-working-in-fedora-linux-upek-147e1000-in-this-case/
Comment 16 Luiz Angelo Daros de Luca 2010-07-26 20:38:40 EDT
Hello,

upeksonly still does not work for me. If someone follows the previous howto, step1 is useless as step2 installs fingerprintGUI and UPEK proprietary library (libbsapi.so):

A specific proprietary (non opensource) driver “libbsapi.so”
from UPEK Inc. (http://www.upek.com/) is available for this device.
To take full advantage of this device, the installation of this driver
is required. Do you want the install script to copy this driver to
“/usr/lib”? (Yes/no): Yes
Driver “libbsapi.so” was copied to “/usr/lib”.

At this point, I can see that libbsapi was installed. However, there is no way to check if it is in use by looking at the pictures.

If you still have this working, open FingerprintGUI, select "Show Drivername" and change the upper combobox from libbsapi (default one) to "UPEK Touchstrip Sensor-Only"

For me, fprint keeps waiting forever on "Scan step" and device becomes unresponsible until next cold reboot.

Should the support using a proprietary driver be considered enough? I guess all tools that depends on fprint must change to also support bsapi.
Comment 17 Bastien Nocera 2010-08-17 14:04:09 EDT
(In reply to comment #15)
> The upeksonly module in libfprint package supports this. But the upeksonly.c
> does not list this particular VID/PID. I tried adding 1470:1000 to the
> supported device table of upeksonly, it works fine. No more "Unknown device".
> Here is how I got it? May be useful for some one.
> 
> http://karuppuswamy.com/wordpress/2010/07/22/how-to-get-fingerprint-reader-working-in-fedora-linux-upek-147e1000-in-this-case/

Given that your post mentions:
> A specific proprietary (non opensource) driver “libbsapi.so”
> from UPEK Inc. (http://www.upek.com/) is available for this device.
> To take full advantage of this device, the installation of this driver
> is required. Do you want the install script to copy this driver to
> “/usr/lib”? (Yes/no): Yes
> Driver “libbsapi.so” was copied to “/usr/lib”.

I'll conclude that the upeksonly driver does not work, unlike what you concluded.

(In reply to comment #9)
> This particular fingerprint reader is also present on a Sony Vaio VGN-BZ12XN.

libfprint will not work with any of the Vaio fingerprint readers, as they're lobotomised versions of the device, and require extra trickery to be able to talk to them (which nobody reversed-engineered).

I'll close this bug as there's no drivers for this device available.

Any other discussions should happen on the libfprint lists.
Comment 18 Bastien Nocera 2010-08-31 12:58:06 EDT
Reopening, the support is now upstream. I'll update the package when I do a new upstream release.
Comment 19 Fedora Update System 2010-09-08 13:11:21 EDT
libfprint-0.3.0-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc14
Comment 20 Fedora Update System 2010-09-08 13:22:50 EDT
libfprint-0.3.0-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc13
Comment 21 Fedora Update System 2010-09-08 14:03:35 EDT
libfprint-0.3.0-1.fc14 has been pushed to the Fedora 14 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 libfprint'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc14
Comment 22 The Source 2010-09-09 11:16:01 EDT
I used fprintd-enroll and fprintd-verify to check the device. The device is opened and scan is successful, but I never could get verify-match result. And I got TONES of try-again. Either it's a bug or I don't understand how this thing works. After many tries fprintd-enroll/verify started to say that they can not claim device (error -4) though no other apps were running.
Comment 23 Bastien Nocera 2010-09-09 18:54:30 EDT
(In reply to comment #22)
> I used fprintd-enroll and fprintd-verify to check the device. The device is
> opened and scan is successful, but I never could get verify-match result. And I
> got TONES of try-again. Either it's a bug or I don't understand how this thing
> works. After many tries fprintd-enroll/verify started to say that they can not
> claim device (error -4) though no other apps were running.

Either file an upstream bug (on freedesktop.org), or e-mail the fprint mailing-list. I don't have the hardware, so I cannot test.
Comment 24 Bruno Medeiros 2010-09-30 00:49:07 EDT
No Fedora 12 packages? I have a device, but only a Fedora 12. If you could provide a patch I can test.
Comment 25 The Source 2010-09-30 02:44:24 EDT
I contacted fprint developers about the issue and they say:
1. The new driver is buggy and a reason for frequent 'try again' in fprintd commands
2. The algorithm for image comparison is very simple and therefore it is quite hard to get a 'match' result. You have to swipe finder almost EXACTLY like first time which is very hard. In Windows the native software works better.

For those reasons I'd rather use passwords for now.
Comment 26 Bug Zapper 2010-11-04 07:38:21 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 27 Fedora Update System 2010-12-04 19:38:22 EST
libfprint-0.3.0-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.