[fprint] RFC: [PATCH] BSAPI bridge driver for libfprint

[Luiz Angelo Daros de Luca]

Hello Chow,

I can confirm that this also works with my device. Probably, it will
work with any supported BSAPI devices.

I am not a fprint commiter and not a fprint master but I have some suggestions.

It should exists a way to switch from/to libfprint native driver
to/from bsapi one. Maybe a env variable? Have the case of multiple
drivers implementing the same device ever happened in fprint? Also, I
think that native upek*.c drivers should have precedence over bsapi
(if not set explicitily by env or compile flag).

The configure script may need some fix like checking for bsapi and
disabling the driver if libs are missing. Configure also does not list
the new driver in the drivers feedback (--with-drivers).

--- libfprint/drivers/bsapi.c.old       2011-07-03 22:54:26.000000000 -0300
+++ libfprint/drivers/bsapi.c   2011-07-03 22:54:50.000000000 -0300
@@ -538,6 +538,7 @@

 /* TODO: Complete listing of usb devices here */
 static const struct usb_id id_table[] = {
+    { .vendor = 0x147e, .product = 0x1000 },
     { .vendor = 0x147e, .product = 0x1002 },
     { 0, 0, 0, },
 };

About this usb_id list, maybe fprint workflow could be adapted to not
use id_table outside the driver. Like, instead of calling discovery
only for drivers that matched in id_table, call for all of them and
let the discover function decides whether it supports or not. Maybe
just swap the precedence of discovery over id_table.
In discover,  ABSEnumerateDevices could detect wheter it is supported
or not (as you already do). This might not be optimized solution but I
guess detecting step might not be too much resource hunger. On this
sollution, the missing part is udev rules, which also uses id_table.

I can help if you need further test on a different device (like mine)

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca at gmail.com



2011/7/3 Luiz Angelo Daros de Luca <luizluca at gmail.com>:
> Hello Chow,
>
> I don't know about the others but I'm really looking for something
> like these. This could also allow some benchmark test between both.
> Also, this could help on reverse engeneering what is different from
> other drivers on your device.
>
> libfprint upek driver, in my case, is still unusable because of its
> poor matching results.
>
> Thanks and I really hope success for you.
>
> I have a 147e:1000 and I will try to test your patch.
>
> Regards,
>
> ---
>      Luiz Angelo Daros de Luca, Me.
>             luizluca at gmail.com
>
>
>
> 2011/6/29 Chow Loong Jin <hyperair at ubuntu.com>:
>> Hi all,
>>
>> Seeing as there are a number of UPEK devices that weren't supported by
>> libfprint, I wrote a "bsapi" driver that uses dlopen to load libbsapi.so from
>> the proprietary UPEK SDK if it is present, allowing libfprint-using applications
>> to access unsupported UPEK devices.
>>
>> I have only been able to test this with the 147e:1002 sensor that is embedded in
>> my Thinkpad Edge E220S, but based on the UPEK SDK documentation, as well as
>> fingerprint-gui which uses libbsapi directly, I think it should work for all
>> other UPEK sensors supported by this library.
>>
>> The driver keeps conveniently out of the way if libbsapi.so is not available by
>> returning an error value in the discover() function.
>>
>>
>> Currently there are a number of caveats in the implementation:-
>> 1. There's no way of telling asking libbsapi how many stages of enrolling are
>>   actually needed, so the driver just pretends there's only one stage.
>>
>> 2. libbsapi has imaging support, but I haven't gotten around to figuring out
>>   how to implement the driver as a fp_img_driver yet. I'll probably look into
>>   it soon.
>>
>> 3. identify_{start,stop}() haven't been implemented. I'll get around to this
>>   soon as well.
>>
>> 4. There is a TODO note near the usb_id table -- only one usbid has been listed
>>   there so far, but ideally all the IDs supported by this driver should be
>>   listed there. I'm not sure where I can get a list though.
>>
>> The patch including this driver is attached. Comments welcome!
>>
>> --
>> Kind regards,
>> Loong Jin
>>
>> _______________________________________________
>> fprint mailing list
>> fprint at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/fprint
>>
>>
>