Well it seems Mepis' default kernel is broken. So I'm going to have to
rebuild the kernel with some features they shut off. I have a Phenom core
(running 32 bit, for a single application required for business, grrr).
Would it be best for me to build to a 686 (the default) processor family?
In case I produce anything useful.
Brian
On Fri, April 29, 2011 5:32 am, Kunal Gangakhedkar wrote:
> On Friday 29 Apr 2011 2:33:42 pm br...@amason.net wrote:
>> Well, I downloaded version 0.4.0 and the latest fprint-demo. fprint-demo
>> doesn't see the fingerprint scanner.
>>
>> However, running the example codes I get this when trying to enroll or
>> verify-live.
>>
>> $sudo ./enroll
>> Found device claimed by Validity VFS101 driver
>> 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.
>> vfs101:error [async_recv_cb] transfer not completed, status = 6
>> async:error [fpi_drvcb_enroll_stage_completed] BUG at async.c:161
>> sync:error [fp_enroll_finger_img] unrecognised return code -5
>> Enroll failed with error -22
>>
>
> Most likely, the protocol is different than vfs101/201.
> Maybe, it has different registers? maybe takes different values for dev
> init?
> who knows?
>
> So, just adding the dev ids in vfs101.c won't help.
>
> We'll need to understand the protocol from usb-sniff logs.
> It's a daunting task, to be honest. VFS101 was made possible due to
> Ray Lehtiniemi's efforts to reverse-engineer the protocol from sniff logs.
> Kudos to him. And of course, vfs101.c primary author - Sergio Cerlesi. :)
>
> Even the current vfs101.c doesn't cover up all the states for my VFS201
> sensor
> - but, at least it can get the image out.
>
>> Now it says VFS101, but I left the code alone and added the VFS301 to
>> the
>> list of supported devices for the driver.
>>
>> $ diff vfs101.c vfs101.c.new
>> 1542a1543
>> > { .vendor = 0x138a, .product = 0x0005 },
>>
>
> That is because you _explicitly_ added the devid in the driver - so, while
> scanning the devices, libfprint sees that vfs101 driver *claims* to
> support
> the device that it found using usb ids.
>
>> ------------------
>> The other examples gave other messages.
>>
>> $sudo ./img_capture
>> Found device claimed by Validity VFS101 driver
>> Opened device. It's now time to scan your finger.
>>
>> image capture failed, code -95
>>
>>
>> Verify failed because the was no file to verify.
>>
>> cpp-test seems to do nothing, but no error.
>>
>
> cpp-test is a simple C++ program that just tries to link to the
> fprint library - to make sure that we can still call the libfprint
> functions from C++ code.
> It doesn't serve any other purpose.
>
>> That's all for tonight (morning). I'll have to dig into the code to see
>> what the messages mean.
>>
>> Brian
>
> IOW, there is a lot more work to be done for Validity sensors.
> We're just starting off with some usable code.
> But, it needs a lot of patience - which, I hope, we'll have ;)
> I'd rather prefer to have an open source driver than anything
> closed-source from Validity Inc. ;)
>
> Kunal
>
>
_______________________________________________
fprint mailing list
fprint@reactivated.net
http://lists.reactivated.net/mailman/listinfo/fprint
