Re: Driver for Microsoft USB Fingerprint Reader

[Daniel Drake]

Daniel Bonekeeper wrote:
> So in this case, instead of having an unique interface to retrieve and
> use fingerprint readers on the kernel space, we should have it on
> userspace ?

Yep - why not (we can do it that way, and it is much easier than doing 
it in kernel space).

> Entirely ?

I guess there may be situations where, if there is a kernel-based 
fingerprint scanning driver, userspace cannot realistically know about 
some of the advanced details that we plan to 'export' for this 
interface. In this case, we'd have to modify the kernel drivers to add 
an interface for this extra information, or just make it add a file to 
sysfs or something like that.

> This will then bind fingerprint applications to
> always use some kind of userspace library or daemon.

Yep. Just like all applications that use scanners use libsane, and there 
are many other examples where the kernel does not provide the full 
solution to a problem.

Not to forget that userspace code is needed to complement any potential 
kernel-side driver anyway - the functionality provided by the 
DigitalPersona and AES4000 scanners (just 2 examples which I know about) 
is so rich that you need an actual userspace library to form the basic 
operations ("scan a finger", etc). Even more so when we figure out how 
to decrypt the images and can enable the image encryption bit. Whether 
in userspace or in kernel, I don't want the driver portion to limit what 
can be done with the devices, since there are so many possibilities.

> If we are to have
> a centralized system to manage that (which we don't have right now),
> and in both situations we're going to need to implement it 

Yep.

> (either at
> kernel level or as some kind of userspace library set and/or a running
> daemon that uses it), I think that it will be better to bind future
> fingerprint applications to the kernel instead of userspace libraries.

While there are viable and workable userspace solutions available, I 
disagree.

> What will happen then if we want to combine fingerprint matching in a
> situation where the userspace isn't available ? Let's say, use a
> fingerprint validation to mount / (I now that this implies having a
> fingerprint match algorithm implemented in kernel, which is out of
> scope).

Do it in an initramfs, just like you would for any other complex 
mounting procedure. I think klibc makes this kind of thing even easier. 
Even if it is out of scope of this discussion, software-based 
fingerprint matching is not practical in kernel space, and I think I can 
safely say that this kind of thing will never be added to the Linux kernel.

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

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.

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

> What about the closed-source SDKs ?

We (as in kernel development community) don't care about them. They can 
do what they want. They can even adapt our GPL code to better suit their 
needs, but we might not accept their changes into the official codebase.

> My point is: if we're going to implement a centralized interface for
> this, and fingerprint applications are to be bound to an API, this API
> should be at the kernel, where there are less chances of each vendor
> having their own API (as it is now in userspace), and less libraries
> or daemons competing between them to be "the default standard for
> fingerprint devices" in linux.

I'm not clear whether you refer to vendors as Linux vendors (e.g. Red 
Hat, Novell, ...) or fingerprint hardware manufacturers (e.g. Digital 
Persona, Authentec).

If you are talking about Linux vendors, I think they would have no 
problem adopting and contributing to an open-source centralized 
fingerprint handling userspace library, and I don't think there would be 
any problems with multiple libraries doing the same thing in the wild, 
unless ours really sucks.

If you are talking about hardware manufacturers, I'd gladly take any 
input they have if they are interested in helping the open source 
development community. I'm sure they have more experience than most of 
we do. I have yet to even get a word of response from Digital Persona 
about my work.

Also, in some ways, competition is good. And doing something at kernel 
level to simply ensure everyone is using the same code and to prevent 
competition is not a strategy that is usually employed.

> I'm currently talking about something much less ambitious... at least
> started like that. Just having a way to tell the userspace the
> capabilities of our fingerprint reader hardware (image resolution,
> image format, etc). In a uniform way (so doesn't matter which reader
> do you have, you can have this information).

Ok. This makes a certain degree of sense, but is making the assumption 
that the kernel actually knows about the fingerprint reader it is 
working with. There aren't enough devices supported to make judgment 
yet, but it appears this will be at least partially false: open-source 
drivers for at least some widely marketed fingerprint readers will be 
implemented purely in userspace.

Either way, I agree with the aim, which is basically to provide a 
generic way for userspace programs to get information about the 
fingerprint reading hardware which they are dealing with.

> Them came the idea of
> putting it on sysfs (since this is already done with sound system,
> net, etc).

Sounds sensible, but only if we are talking about kernel drivers. 
Putting information into syfs about devices which the kernel knows 
almost nothing about is not very realistic, unless you have a masterplan.

> Then came the idea of extending it to all devices and
> BUSes, not just USB fingerprint (which got off-topic).

This is ambitious (just by sheer scope) but is an admirable effort: it 
would rock if more device-specific information is available in sysfs, 
but again, it only makes sense where the kernel itself is powering the 
hardware.

> > > but this sounds to me more like a
> > > decision made by fingerprint devices manufactures
> >
> > It's not their decision while they aren't the ones writing the drivers.
>
> Actually they are, since I'm referring to the userspace SDK that they
> provide, which access the /dev/usb* stuff directly to talk directly
> with the fingerprint readers.

Are you referring to open source SDKs? If you are, I'd love to hear 
about them. If you aren't, its not something that we really care about. 
They are free to work without the support of the community if they choose.

> Are there independent developers
> developing userspace drivers for fingerprint readers on linux (i.e.,
> aren't tied to any vendor) ?

I don't know.

Anyway, let me make a statement in response to your mails which I'm sure 
will be corrected by Greg or someone else if I'm talking rubbish:

Various USB devices are *not* handled by the kernel. However, these 
devices are usable on Linux/FreeBSD/Windows via userspace libusb-based 
driver code. These drivers will *not* be moved into the Linux kernel 
unless there is a strong reason to do so. This also applies to the 
in-development USB fingerprint reader drivers in userspace: they won't 
be moved into the kernel unless there is a real need to. The ideas you 
have presented so far do not justify that move.

So, if you are designing some kind of information abstraction for all 
USB fingerprint readers, or even all USB devices, or even the spectrum 
of all devices which includes USB, you *cannot* realistically do this at 
kernel level because the kernel has no clue about some of the devices it 
is operating. This is a significant problem with your otherwise 
convincing ideas up to this point, and is something you need to think 
about in other ways than moving things into the kernel.

I hope this makes some sense!

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/