Re: Driver for Microsoft USB Fingerprint Reader

["Daniel Bonekeeper" <thehazard@gmail.com>]

>
> > If we are to have all the fingerprint readers interfaces in usermode,
> > how will this be done ?
>
> Good question. I haven't thought a great deal about it, as I mentioned
> before my TODO list is:
> 1. Get dpfp/libdpfp stable
> 2. Find or write some code which can reliably compare fingerprint
> images, hook dpfp up to that as a prototype
> 3. Solve the larger problem of finding a way to abstract fingerprint
> reading devices (and fingerprint comparison) into a common API for mass
> adoption.
>
> I'm still on (1), but I'm really glad that people are showing interest
> in (2) and (3).

Do you currently have any page/doc/wiki about the current efforts in
writing an API to handle fingerprint stuff ? (as in (3))

> Anyway, here's a really rough plan for (3): compare a number of
> fingerprint readers, looking at the functionality they offer. Find a way
> to abstract the common functionality into an API which would be used by
> a higher level. Add some API and code to compare fingerprint images, and
> maybe to glue the two together (scanning and matching). Design a modular
> system so that (to a certain extent) support for fingerprint scanning
> devices can be 'plugged in' to provide some of the functionality behind
> the scanning API that has been previously defined.
>

Yeah, that's the idea that I had in mind at first. I/we could start by
taking a look on the current API implementations from the most common
devices to get a whole idea of what's involved (for example some fancy
readers may provide ways to control a LED that indicates the state of
the device, etc, and it may be programmable, others not). We could put
everything in a Wiki separated by devices, and fix a date where we can
start discussing the first API.

> > Let's take in consideration the number of currently available usermode
> > drivers for fingerprint readers: if we are to have a centralized
> > interface to manage all the different types of fingerprint readers, we
> > need to keep this somewhere (a daemon or library providing an API to
> > access the devices in an uniform way).
>
> Yep.
>
> > In both cases, an effort is
> > involved in porting the currently available SDKs to this API in order
> > to get it working.
>
> Yep, except there aren't really any current SDKs/APIs. As I said before,
> the only driver I know about is idmouse and that doesn't offer any
> recognition capabilities, infact it doesn't even offer finger detection
> (you ask it for an image, and it will take a photo of thin air if there
> is no finger there). I don't know much about the driver or hardware, but
> I think idmouse will need to be reworked before it becomes useful.
>
> So basically we're starting from scratch.
>

Sweet =)

Well.. I was thinking about keeping that stuff on kernel more for
conservative reasons (driver == kernel). I really would like the idea
of having something very nice (and under a standard) to have
information about the devices on the system, as sysfs is progressing
to do so. I already explained in earlier e-mails about what I had in
mind, but it can only, of course, run in kernel mode. Mixing userspace
and kernel mode drivers will mess it up anyways. Imagine my wonderful
world: every device and information that you may want to know about
any device on your system is on /sys, and not only "obscure" things
like BUS ID, vendor ID, etc, but userspace-useful info like
resolution, capabilities, etc. A tool like "si" could easily parse
/sys to show everything about your system. And since all drivers (in
kernelspace) are specifically implemented to handle their devices,
they can know _exactly_ their properties, and export them.

In the real world, however, if we want to have information about our
devices, we need to sweat it from a range of ioctl()'s, /dev's and
userspace devices (sometimes direct access to memory, as I think that
the (old?) superprobe used to do). Since sysfs is an effort (between
others) to centralize such informations, why blow it by sparsing
information onto userspace ?

Even though I believe that the place for drivers is in the kernel, I
don't have _practical_ reasons to insist on that (at least for
fingerprint devices), and as I can see that this concept of userspace
vs. kernelspace drivers was already heavily discussed, I won't sweat
to find a reason to get it into the kernel... Just feel that would be
good to have everything under one single place, sounding more like a
standard.

Anyways, how idmouse got into the mainstream kernel, then ?

Daniel

-- 
What this world needs is a good five-dollar plasma weapon.