> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
