We can avoid having multiple device feature-check functions now and
just rely on a few.
Add uncrustify config to properly handle begin/end deprecation macros.
Some devices have storage but that's is limited enough not to be able
to store all the metadata, but just a fingerprint id.
In such case we also need to use the local storage to be able to verify.
Fprintd does this already, but we don't do it in the libfprint examples.
So, in in case we enroll, always save the print information to the disk,
while in case we verify we try to load the print from disk and we use
that in case its private data matches the one provided by the device.
Adding a trailing \n to g_message, g_debug, g_warning and g_error is not
neccessary, as a newline will be added automatically by the logging
infrastructure.
Promptly show the match/no-match result in the match callback instead of
waiting the verification process to be finished.
Also exit in case of an hard error, while permit to try again in case of a
retry error.
It is a good idea to report match results early, to e.g. log in a user
immediately even if more device interaction is needed. Add new _full
variants for the verify/identify functions, with a corresponding
callback. Also move driver result reporting into new
fpi_device_{identify,verify}_report functions and remove the reporting
from the fpi_device_{identify,verify}_complete calls.
Basic updates to code is done in places. Only the upekts driver is
actually modified from a behaviour point of view. The image driver code
should be restructured quite a bit to split the reporting and only
report completion after device deactivation. This should simplifiy the
code quite a bit again.
While there are various functions which similar usage in all the examples,
I'd prefer to keep each example to be self-containing most of the things.
However some clearly repeated action can be moved to a single codebase.
The only API user currently seems to be the examples. fprintd has its
own storage and that will be a good idea in general.
So deprecate the API, we'll need to find a different solution for the
examples eventually.
Added new API functions to obtain images, even when scans are bad, perhaps
a useful way to show the user just how good/bad the scan actually was.
Drivers and examples updated accordingly.
The basic model is that image drivers declare a fp_img_driver structure
rather than a fp_driver struct. fp_img_driver will contain primitive imaging
operations such as 'scan finger and return image'. The imgdev layer will
generically implement the primitive fp_driver operations, and the imgdev
layer will fix up the enroll/verify/etc pointers at driver registration
time.
Removed const from all fp_driver declarations, as these are now modified
dynamically in the case of imaging drivers.
Prints can now be saved to disk (but you currently must classify which
finger they are) and you can load them later.
Added 2 simple example programs to demonstrate this.
Convert enrollment function to return a signed integer, which is negative
on error or corresponds into fp_enroll_result otherwise.
Now we can treat a 'FAIL' condition differently from an actual error: fail
means that enrollment didn't complete because the data was nonsense or
whatever (e.g. scanned a different finger for each stage?).
Updated upekts accordingly.
upekts will need to know when the first enrollment stage is attempted for
the first time, so add an __enroll_stage counter which actually indicates
the next stage to enroll. -1 is a special value and it means 0 is next *and*
it is the initial attemt.
Added more debug output to the enroll handler.
Added new fp_enroll_status codes for too short or uncentered scans.
Changed the print_data allocator to consider the device rather than the
driver, this feels more natural. Added missing return value.
Make fp_enroll_status codes start at 1. 0 can now be used as a
special/temporary value by the drivers. Also check that we aren't exceeding
the number of enroll stages.
Also add a missing exit() call to the verify example and update for the
above.
