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

[Chow Loong Jin]

Hello Luiz,

On 04/07/2011 10:47, Luiz Angelo Daros de Luca wrote:
> 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)

Currently, the bsapi driver only activates when libbsapi.so is found. I believe
a valid assumption would be that people who have the proprietary libbsapi.so
installed would want the driver to override the native driver.

On the other hand, like you mentioned, an environment variable would be useful
to force the bsapi driver to not even try loading the library. I'll add support
for that in the discover() function.

> 
> 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).

Ah, I missed that out in the configure script. I'll fix it up.

> --- 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 think such a change would be pretty invasive, and would be good for a later
patch, perhaps.

-- 
Kind regards,
Loong Jin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/fprint/attachments/20110705/34fdfda4/attachment.pgp>