197edac702
Instead of adding driver IDs by hand to a header file, generate the driver ID from the (hopefully unique) name of the driver. This means one file less for driver authors to modify, and one possible source of merge conflicts less as well. However, this means that already enrolled fingerprints will need to be enrolled again, as the driver IDs will have changed compared to their old on-disk value.
112 lines
5.2 KiB
XML
112 lines
5.2 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
|
]>
|
|
<chapter id="advanced-topics" xmlns:xi="http://www.w3.org/2003/XInclude">
|
|
<title>Advanced Topics</title>
|
|
|
|
<refsect2 id="compatibility">
|
|
<title>Device and print compatibility</title>
|
|
|
|
<para>
|
|
Moving off generic conceptual ideas and onto libfprint-specific
|
|
implementation details, here are some introductory notes regarding how
|
|
libfprint copes with compatibility of fingerprints.
|
|
</para>
|
|
|
|
<para>
|
|
libfprint deals with a whole variety of different fingerprint readers and
|
|
the design includes considerations of compatibility and interoperability
|
|
between multiple devices. Your application should also be prepared to
|
|
work with more than one type of fingerprint reader and should consider that
|
|
enrolled fingerprint X may not be compatible with the device the user has
|
|
plugged in today.
|
|
</para>
|
|
|
|
<para>
|
|
libfprint implements the principle that fingerprints from different devices
|
|
are not necessarily compatible. For example, different devices may see
|
|
significantly different areas of fingerprint surface, and comparing images
|
|
between the devices would be unreliable. Also, devices can stretch and
|
|
distort images in different ways.
|
|
</para>
|
|
|
|
<para>
|
|
libfprint also implements the principle that in some cases, fingerprints
|
|
<emphasis>are</emphasis> compatible between different devices. If you go and buy two
|
|
identical fingerprint readers, it seems logical that you should be able
|
|
to enroll on one and verify on another without problems.
|
|
</para>
|
|
|
|
<para>
|
|
libfprint takes a fairly simplistic approach to these issues. Internally,
|
|
fingerprint hardware is driven by individual drivers. libfprint enforces
|
|
that a fingerprint that came from a device backed by driver X is never
|
|
compared to a fingerprint that came from a device backed by driver Y.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, libfprint is designed for the situation where a single driver
|
|
may support a range of devices which differ in imaging or scanning
|
|
properties. For example, a driver may support two ranges of devices which
|
|
even though are programmed over the same interface, one device sees
|
|
substantially less of the finger flesh, therefore images from the two
|
|
device types should be incompatible despite being from the same driver. To
|
|
implement this, each driver assigns a <emphasis>device type</emphasis> to each device
|
|
that it detects based on its imaging characteristics. libfprint ensures that
|
|
two prints being compared have the same device type.
|
|
</para>
|
|
|
|
<para>
|
|
In summary, libfprint represents fingerprints in several internal structures
|
|
and each representation will offer you a way of determining the
|
|
<ulink url="#driver_id">driver ID</ulink> and <ulink url="#device-types">devtype</ulink> of the print in
|
|
question. Prints are only compatible if the driver ID <emphasis role="strong">and</emphasis> devtypes
|
|
match. libfprint does offer you some "is this print compatible?" helper
|
|
functions, so you don't have to worry about these details too much.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="driver_id">
|
|
<title>Driver IDs</title>
|
|
|
|
<para>
|
|
Each driver is assigned a unique ID automatically based on the driver name.
|
|
</para>
|
|
|
|
<para>
|
|
The only reason you may be interested in retrieving the driver ID for a
|
|
driver is for the purpose of checking if some print data is compatible
|
|
with a device. libfprint uses the driver ID as one way of checking that
|
|
the print you are trying to verify is compatible with the device in
|
|
question - it ensures that enrollment data from one driver is never fed to
|
|
another. Note that libfprint does provide you with helper functions to
|
|
determine whether a print is compatible with a device, so under most
|
|
circumstances, you don't have to worry about driver IDs at all.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="device-types">
|
|
<title>Device types</title>
|
|
|
|
<para>
|
|
Internally, the <ulink url="libfprint-Driver-operations.html#libfprint-Driver-operations.description">driver</ulink> behind a device assigns a 32-bit
|
|
<emphasis>devtype</emphasis> identifier to the device. This cannot be used as a unique
|
|
ID for a specific device as many devices under the same range may share
|
|
the same devtype. The devtype may even be 0 in all cases.
|
|
</para>
|
|
|
|
<para>
|
|
The only reason you may be interested in retrieving the devtype for a
|
|
device is for the purpose of checking if some print data is compatible
|
|
with a device. libfprint uses the devtype as one way of checking that the
|
|
print you are verifying is compatible with the device in question - the
|
|
devtypes must be equal. This effectively allows drivers to support more
|
|
than one type of device where the data from each one is not compatible with
|
|
the other. Note that libfprint does provide you with helper functions to
|
|
determine whether a print is compatible with a device, so under most
|
|
circumstances, you don't have to worry about devtypes at all.
|
|
</para>
|
|
</refsect2>
|
|
|
|
</chapter>
|