Juan Antonio Martinez wrote: > 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...
I made the decision *not* to allow external drivers of any kind, deliberately. I was worried that fprint may become the defacto standard for fingerprint scanners, and then vendors would start producing binary drivers which would gain lots of adoption and cause us lots of headaches. I want everything open and in one place, like how it works with drivers in the kernel. I am still not interested in interacting with closed drivers, but I am prepared to add the functionality necessary for some of the "good" use-cases that have been described here. e.g. capturing the fingerprint image on a very low spec machine where mindtct would take minutes, sending the image data to a high-spec machine to do the actual processing. That may make it possible for external drivers to interact with fprint, an unwanted (but reluctantly accepted) side effect. Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
