Sébastien Morin | 1 Dec 13:35 2007
Picon

U.are.U 4000 Reader

I got my hand on a 4000 model and when I try to use it with the fprint_demo application, the application just freeze.

I tried using the device in vmware with one of the digital persona application and the scanner works.

When I came back to try it again with fprint_demo, this time it worked, but the image was encrypted.

I think there is something different in the initialization of the device between the 4000 and 4000B models.

I've been able to borrow a 4000B model and fprint_demo works well with it.

Is there anything I could do to help ?

thanks

--
Sébastien Morin
smsisko <at> gmail.com

--
Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. -- Karl Lehenbauer

_______________________________________________
fprint mailing list
fprint <at> reactivated.net
http://lists.reactivated.net/mailman/listinfo/fprint
Daniel Drake | 1 Dec 13:44 2007
Picon

Re: U.are.U 4000 Reader

Sébastien Morin wrote:
> I got my hand on a 4000 model and when I try to use it with the 
> fprint_demo application, the application just freeze.

Please define "use it". Also configure libfprint with 
--enable-debug-log, recompile, and post stdout/stderr logs from your 
fprint_demo session.

> I think there is something different in the initialization of the device 
> between the 4000 and 4000B models.

Yes, there is, and libfprint should support both. However, my own UareU 
4000 is broken so I am unable to test. I will have a new one in my hands 
in about 2 weeks time.

> I've been able to borrow a 4000B model and fprint_demo works well with it.
> 
> Is there anything I could do to help ?

Does dpfp/libdpfp work?
Do the libfprint example programs work?

Daniel
Daniel Drake | 1 Dec 13:53 2007
Picon

Re: discover_device function in examples

Andrei Tchijov wrote:
> Not a major thing .... but. All examples for libfprint use function  
> "discover_device" which looks strange:
> 
> struct fp_dscv_dev *discover_device(struct fp_dscv_dev  
> **discovered_devs)
> {
> 	struct fp_dscv_dev *ddev = NULL;
> 	int i;
> 
> 	for (i = 0; ddev = discovered_devs[i]; i++) {
> 		struct fp_driver *drv = fp_dscv_dev_get_driver(ddev);
> 		printf("Found device claimed by %s driver\n",
> 			fp_driver_get_full_name(drv));
> 		return ddev;
> 	}
> 
> 	return ddev;
> }
> 
> Unless I am greatly mistaken, "for" loop will run once (if  
> discovered_devs is not empty) regardless of anything.

I wonder what I was thinking there. It's just supposed to select the 
first device on the bus. No loop needed, obviously.

> struct fp_dscv_dev *discover_device(struct fp_dscv_dev  
> **discovered_devs)
> {
> 	struct fp_dscv_dev *ddev = NULL;
> 	int i;
> 
> 	for (i = 0; ddev = discovered_devs[i]; i++) {
> 		struct fp_driver *drv = fp_dscv_dev_get_driver(ddev);
> 		if( drv ) {

Fair guess, but for a valid device, driver will never be NULL.

I'll fix this for the next release.

Thanks,
Daniel
Daniel Drake | 1 Dec 15:19 2007
Picon

Re: U.are.U 4000 Reader

Please use reply-to-all

Sébastien Morin wrote:
> 
> 
> On Dec 1, 2007 7:44 AM, Daniel Drake <dan <at> reactivated.net 
> <mailto:dan <at> reactivated.net>> wrote:
> 
>     Sébastien Morin wrote:
>      > I got my hand on a 4000 model and when I try to use it with the
>      > fprint_demo application, the application just freeze.
> 
>     Please define "use it". Also configure libfprint with
>     --enable-debug-log, recompile, and post stdout/stderr logs from your
>     fprint_demo session.
> 
> 
> I was trying to enroll a finger in fprint_demo, this is the log that I 
> get when I do that:
> 
> fp:debug [fp_init]
> fp:debug [register_driver] registered driver upekts
> fp:debug [register_driver] registered driver uru4000
> fp:debug [register_driver] registered driver aes1610
> fp:debug [register_driver] registered driver aes2501
> fp:debug [register_driver] registered driver aes4000
> fp:debug [register_driver] registered driver upektc
> fp:debug [find_supporting_driver] driver uru4000 supports USB device 
> 05ba:0007
> uru4000:debug [get_hwstat] val=01
> uru4000:debug [set_hwstat] val=81
> uru4000:debug [fix_firmware] encryption byte at 793 reads 17
> uru4000:debug [fix_firmware] fixed encryption byte to 07
> uru4000:debug [set_hwstat] val=01
> uru4000:debug [get_hwstat] val=00
> uru4000:debug [get_irq_with_type] type=56aa
> uru4000:debug [get_irq] irq type 56aa
> fp:debug [fp_dev_open]
> fp:debug [load_from_file] from /home/smsisko/.fprint/prints/0002/00000000/7
> fp:debug [fp_print_data_from_data] buffer size 2414
> fp:debug [print_data_new] length=2404 driver=02 devtype=0000
> fp:debug [fp_enroll_finger_img] uru4000 will handle enroll stage 0/0 
> (initial)
> fp:debug [fpi_imgdev_capture] uru4000 will handle capture request
> uru4000:debug [set_mode] 10
> uru4000:debug [get_irq_with_type] type=0101
> uru4000:debug [get_irq] irq type 0200
> 
> It just stays stuck like that, at that point I have to kill the software.

Finger-on-sensor detection is not working.

>     Does dpfp/libdpfp work? 
> 
>  
> It seem to have a similar problem, here is the output of running the 
> capture_finger example program:
> 
> dpfp_get_hwstat: [1] 3
> dpfp_set_mode: 0
> dpfp_set_hwstat_pwr: power off
> dpfp_set_hwstat_pwr: power on
> dpfp_get_irq: irq type 56aa
> place your finger on the sensor
> dpfp_set_mode: 10
> dpfp_get_irq: irq type 0200
> dpfp_get_irq: timeout, retry
> dpfp_get_irq: timeout, retry
> 

Same again.

> 
>     Do the libfprint example programs work?
> 
> 
> It basically have the same log as the fprint_demo program plus the 
> example output.

What about img_capture_continuous? That one has no finger-on-sensor 
detection.

Thanks,
Daniel
Sébastien Morin | 1 Dec 15:47 2007
Picon

Re: U.are.U 4000 Reader



On Dec 1, 2007 9:19 AM, Daniel Drake <dan <at> reactivated.net> wrote:

What about img_capture_continuous? That one has no finger-on-sensor
detection.


Here is the output from the log, and the image stays blank:

fp:debug [fp_init]
fp:debug [register_driver] registered driver upekts
fp:debug [register_driver] registered driver uru4000
fp:debug [register_driver] registered driver aes1610
fp:debug [register_driver] registered driver aes2501
fp:debug [register_driver] registered driver aes4000
fp:debug [register_driver] registered driver upektc
fp:debug [find_supporting_driver] driver uru4000 supports USB device 05ba:0007
Found device claimed by Digital Persona U.are.U 4000/4000B driver
uru4000:debug [get_hwstat] val=85
uru4000:debug [do_init] rebooting device power
uru4000:debug [set_hwstat] val=05
uru4000:debug [get_hwstat] val=00
uru4000:debug [get_hwstat] val=05
uru4000:debug [set_hwstat] val=85
uru4000:debug [fix_firmware] encryption byte at 793 reads 07
uru4000:debug [set_hwstat] val=05
uru4000:debug [get_hwstat] val=00
uru4000:debug [get_irq_with_type] type=56aa
uru4000:debug [get_irq] irq type 56aa
fp:debug [fp_dev_open]
using Xv format 0x32595559 YUY2 packed
using Xv format 0x32595559 YUY2 packed
Press S to toggle standardized mode, Q to quit
fp:debug [fpi_imgdev_capture] uru4000 will handle capture request
uru4000:debug [set_mode] 20
fp:debug [fpi_img_new] length=111424

However if I try with the 4000B I get the image for each frame...

As far as I can tell the debug output is basically the same for either devices.

--
Sébastien Morin
smsisko <at> gmail.com

_______________________________________________
fprint mailing list
fprint <at> reactivated.net
http://lists.reactivated.net/mailman/listinfo/fprint
Daniel Drake | 1 Dec 16:04 2007
Picon

Re: U.are.U 4000 Reader

Sébastien Morin wrote:
> 
> 
> On Dec 1, 2007 9:19 AM, Daniel Drake <dan <at> reactivated.net 
> <mailto:dan <at> reactivated.net>> wrote:
> 
> 
>     What about img_capture_continuous? That one has no finger-on-sensor
>     detection.
> 
> 
> Here is the output from the log, and the image stays blank:

What do you mean by 'blank'?

> fp:debug [fp_init]
> fp:debug [register_driver] registered driver upekts
> fp:debug [register_driver] registered driver uru4000
> fp:debug [register_driver] registered driver aes1610
> fp:debug [register_driver] registered driver aes2501
> fp:debug [register_driver] registered driver aes4000
> fp:debug [register_driver] registered driver upektc
> fp:debug [find_supporting_driver] driver uru4000 supports USB device 
> 05ba:0007
> Found device claimed by Digital Persona U.are.U 4000/4000B driver
> uru4000:debug [get_hwstat] val=85
> uru4000:debug [do_init] rebooting device power
> uru4000:debug [set_hwstat] val=05
> uru4000:debug [get_hwstat] val=00
> uru4000:debug [get_hwstat] val=05
> uru4000:debug [set_hwstat] val=85
> uru4000:debug [fix_firmware] encryption byte at 793 reads 07
> uru4000:debug [set_hwstat] val=05
> uru4000:debug [get_hwstat] val=00
> uru4000:debug [get_irq_with_type] type=56aa
> uru4000:debug [get_irq] irq type 56aa
> fp:debug [fp_dev_open]
> using Xv format 0x32595559 YUY2 packed
> using Xv format 0x32595559 YUY2 packed
> Press S to toggle standardized mode, Q to quit
> fp:debug [fpi_imgdev_capture] uru4000 will handle capture request
> uru4000:debug [set_mode] 20
> fp:debug [fpi_img_new] length=111424

Do the last 3 lines only appear once, or do they repeat?

Daniel
Sébastien Morin | 1 Dec 16:12 2007
Picon

Re: U.are.U 4000 Reader



On Dec 1, 2007 10:04 AM, Daniel Drake <dan <at> reactivated.net> wrote:
Sébastien Morin wrote:
>
>
> On Dec 1, 2007 9:19 AM, Daniel Drake <dan <at> reactivated.net
> <mailto: dan <at> reactivated.net>> wrote:
>
>
>     What about img_capture_continuous? That one has no finger-on-sensor
>     detection.
>
>
> Here is the output from the log, and the image stays blank:

What do you mean by 'blank'?

The image is just white, there is absolutely nothing else, if I press "S" to go to standardisez mode it is all black.
 
I can send a screenshot if you want ?


> fp:debug [fp_init]
> fp:debug [register_driver] registered driver upekts
> fp:debug [register_driver] registered driver uru4000
> fp:debug [register_driver] registered driver aes1610
> fp:debug [register_driver] registered driver aes2501
> fp:debug [register_driver] registered driver aes4000
> fp:debug [register_driver] registered driver upektc
> fp:debug [find_supporting_driver] driver uru4000 supports USB device
> 05ba:0007
> Found device claimed by Digital Persona U.are.U 4000/4000B driver
> uru4000:debug [get_hwstat] val=85
> uru4000:debug [do_init] rebooting device power
> uru4000:debug [set_hwstat] val=05
> uru4000:debug [get_hwstat] val=00
> uru4000:debug [get_hwstat] val=05
> uru4000:debug [set_hwstat] val=85
> uru4000:debug [fix_firmware] encryption byte at 793 reads 07
> uru4000:debug [set_hwstat] val=05
> uru4000:debug [get_hwstat] val=00
> uru4000:debug [get_irq_with_type] type=56aa
> uru4000:debug [get_irq] irq type 56aa
> fp:debug [fp_dev_open]
> using Xv format 0x32595559 YUY2 packed
> using Xv format 0x32595559 YUY2 packed
> Press S to toggle standardized mode, Q to quit
> fp:debug [fpi_imgdev_capture] uru4000 will handle capture request
> uru4000:debug [set_mode] 20
> fp:debug [fpi_img_new] length=111424

Do the last 3 lines only appear once, or do they repeat?


Yes they do, until I exit the application at wich point I get:

fp:debug [fp_dev_close]
uru4000:debug [set_mode] 00
uru4000:debug [set_hwstat] val=80
fp:debug [fp_exit]



--
Sébastien Morin
smsisko <at> gmail.com

_______________________________________________
fprint mailing list
fprint <at> reactivated.net
http://lists.reactivated.net/mailman/listinfo/fprint
Daniel Drake | 1 Dec 16:25 2007
Picon

Re: U.are.U 4000 Reader

Sébastien Morin wrote:
> The image is just white, there is absolutely nothing else, if I press 
> "S" to go to standardisez mode it is all black.

OK. The device is not detecting fingers and is sending pure-white 
images. This is the same problem as my own device, which I assumed was 
broken, but maybe it isn't.

The next thing to do would be to capture USB bus traffic from windows. 
You can use http://www.pcausa.com/Utilities/UsbSnoop/default.htm to do 
this. Please try and keep the session short -- plug in the device, wait 
2 seconds, do a quick scan, wait 2 seconds, unplug.

Please then open a bug at http://www.reactivated.net/fprint/bugs/ about 
this. Compress the log, and assuming it is less than 100kb compressed in 
size, attach it there (otherwise please put it on some other web hosting 
instead).

The resultant log will contain an encrypted image of your fingerprint. 
We don't know how to decrypt the data, but nevertheless if you are 
concerned about privacy feel free to email me the log privately instead.

Daniel
Daniel Drake | 3 Dec 00:26 2007
Picon

New subproject: fpusb

libfprint currently uses libusb for USB I/O. It has been working well 
but limits our horizons - it makes cleanly implementing some advanced 
features difficult/impossible and prevents us from providing a 
non-blocking API to library users.

I considered switching to OpenUSB but decided that I do not like their 
solution for a few reasons.

So I wrote my own USB access library called fpusb.

http://www.reactivated.net/fprint/wiki/Fpusb

I will soon start a new libfprint branch in the git repository where I 
convert us to fpusb and then start using the advanced features (involves 
quite a bit of internal reworking, including rewrites of all drivers). 
The basic model is that all drivers will be nonblocking and will 
asynchronously drive the library. The library will provide an 
asynchronous API to users, as well as a synchronous API (basically just 
wrapping the async stuff) similar to the one currently offered.

This new branch will likely be rebased without warning until we reach 
the point where I merge it into the master branch.

Unfortunately, the switch to fpush means that portability is somewhat 
reduced. Previously, libfprint was likely to be portable to OSX and 
windows without too much hassle (because libusb is ported to those 
platforms). fpusb only runs on Linux. I hope that people will become 
interested in porting it, but as I am not going to do this myself, I 
cannot say if/when it might become possible to run libfprint on other 
platforms.

This is not an easy decision to make, but the advantages of having 
asynchronous USB I/O access are significant, and exposing a nonblocking 
interface is important for good library design.

Daniel
Andrei Tchijov | 3 Dec 15:30 2007

Re: New subproject: fpusb

Daniel,
	I am sorry to say, but I am the one of "people" who will be not happy  
with this development.  I start using your drivers when it was dpfp  
and was able to port it to Mac OS X/Windows(cygwin)/Solaris without  
many difficulties.  I was (and still is) very excited about fprint  
project -- mainly because much wider support for scanners.  Just last  
week, I was able to "port" fprint to Mac OS X in about an hour.   
Switch away from libusb  will be rather unfortunate development for my  
projects.
	Maybe I am missing something, but what are the benefits of  
"asynchronous API"?  It is easy enough to start new thread for  
anything that needs to be done "asynchronously". Could you please  
elaborate a little bit about why "asynchronous API" is so appealing?   
In general non-blocking APIs are beneficial in situations when you  
need to wait on many (100s-1000s) data sources -- like in case of web  
servers with bunch of users -- I can not imagine situation when fprint  
will be used to wait on more then one data source at a time.  Am I  
missing something?

Andrei Tchijov
	

On Dec 2, 2007, at 18:26 , Daniel Drake wrote:

> libfprint currently uses libusb for USB I/O. It has been working well
> but limits our horizons - it makes cleanly implementing some advanced
> features difficult/impossible and prevents us from providing a
> non-blocking API to library users.
>
> I considered switching to OpenUSB but decided that I do not like their
> solution for a few reasons.
>
> So I wrote my own USB access library called fpusb.
>
> http://www.reactivated.net/fprint/wiki/Fpusb
>
> I will soon start a new libfprint branch in the git repository where I
> convert us to fpusb and then start using the advanced features  
> (involves
> quite a bit of internal reworking, including rewrites of all drivers).
> The basic model is that all drivers will be nonblocking and will
> asynchronously drive the library. The library will provide an
> asynchronous API to users, as well as a synchronous API (basically  
> just
> wrapping the async stuff) similar to the one currently offered.
>
> This new branch will likely be rebased without warning until we reach
> the point where I merge it into the master branch.
>
> Unfortunately, the switch to fpush means that portability is somewhat
> reduced. Previously, libfprint was likely to be portable to OSX and
> windows without too much hassle (because libusb is ported to those
> platforms). fpusb only runs on Linux. I hope that people will become
> interested in porting it, but as I am not going to do this myself, I
> cannot say if/when it might become possible to run libfprint on other
> platforms.
>
> This is not an easy decision to make, but the advantages of having
> asynchronous USB I/O access are significant, and exposing a  
> nonblocking
> interface is important for good library design.
>
> Daniel
> _______________________________________________
> fprint mailing list
> fprint <at> reactivated.net
> http://lists.reactivated.net/mailman/listinfo/fprint

Gmane