17 Mar 2009 09:15
Re: Integrating a closed-source driver
Juan Antonio Martinez <juan_a_mtnez <at> hotmail.com>
2009-03-17 08:15:45 GMT
2009-03-17 08:15:45 GMT
> Alain M. wrote:
> > Do you nean that if I hava an image (generic, 500dpi, 8bits, gray scale)
> > I cannot feed it to fprint????
>
> Yes. It was intentionally made this way to make sure that all drivers
> are open source and kept within fprint.
Sometime ago I was working in OpenSC, a project to handle cryptographic
cards. Some similar problem arised with proprietary cards and reader drivers
Our solution was to provide a generic interface to the driver layer, and
define a "generic" card: a simply wrapper to talk via socket (or dll, or so)
with a propietary driver...
Same concepts may apply here: In our project, it's not enought to tell
yes or no to a PKI certificate match: proprietary driver _must_ comply
with interface API. In fprint is not enought to tell "image match":
proprietary driver should comply libfprint driver api.
As LGPL allows linking with proprietary drivers no problem should arise
( having in mind that driver code cannot be mixed with fprint code, just
being dll'd or connected via "generic driver socket interface" -or so-).
The problem and headaches relies on provider of proprietary driver:
fprint only grants that API is exposed. I'ts provider bussiness to get care
on being up-to-date with api changes and related problems... As in
OpenSC case, most proprietary driver providers choose (with some
minor reluctant exceptions ) to get their drivers free, to allow integration
with main project, and forget update API integration tasks
So my proposal is ¿why not provide and expose a generic driver API to
allow proprietary (or free) fingerprint readers drivers to connect with
libfprint?.
Juan Antonio
(Some day my Dell's AES2810 will be supported...
)
PS: not related, but I've seen that upcoming Fedora 11 features
parallel pam stacks to allow multiple simultaneous ways to
authenticate, and integrates OpenSC, fprint and so...
Diferentes formas de estar en contacto con amigos y familiares. Descúbrelas. Descúbrelas.
> > Do you nean that if I hava an image (generic, 500dpi, 8bits, gray scale)
> > I cannot feed it to fprint????
>
> Yes. It was intentionally made this way to make sure that all drivers
> are open source and kept within fprint.
Sometime ago I was working in OpenSC, a project to handle cryptographic
cards. Some similar problem arised with proprietary cards and reader drivers
Our solution was to provide a generic interface to the driver layer, and
define a "generic" card: a simply wrapper to talk via socket (or dll, or so)
with a propietary driver...
Same concepts may apply here: In our project, it's not enought to tell
yes or no to a PKI certificate match: proprietary driver _must_ comply
with interface API. In fprint is not enought to tell "image match":
proprietary driver should comply libfprint driver api.
As LGPL allows linking with proprietary drivers no problem should arise
( having in mind that driver code cannot be mixed with fprint code, just
being dll'd or connected via "generic driver socket interface" -or so-).
The problem and headaches relies on provider of proprietary driver:
fprint only grants that API is exposed. I'ts provider bussiness to get care
on being up-to-date with api changes and related problems... As in
OpenSC case, most proprietary driver providers choose (with some
minor reluctant exceptions ) to get their drivers free, to allow integration
with main project, and forget update API integration tasks
So my proposal is ¿why not provide and expose a generic driver API to
allow proprietary (or free) fingerprint readers drivers to connect with
libfprint?.
Juan Antonio
(Some day my Dell's AES2810 will be supported...
)PS: not related, but I've seen that upcoming Fedora 11 features
parallel pam stacks to allow multiple simultaneous ways to
authenticate, and integrates OpenSC, fprint and so...
Diferentes formas de estar en contacto con amigos y familiares. Descúbrelas. Descúbrelas.
_______________________________________________ fprint mailing list fprint <at> reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
RSS Feed