We can just use a GTask to handle the detection while using the
finish function to process the results to the image, so that it
is more predictable when this happens and it does not depend on
a thread returning.
Also remove data duplication when possible, this class wasn't
fully safe anyway to be used concurrently, so there's no point
to copy data when not needed. Also added the hard constraint to
not proceed with minutiae detection if something else is already
doing this.
At the same time we can mark the task to finish early on
cancellation.
As suggested by @benzea, the following cleanup actions have been
performed:
- let case order match enroll states enum
- remove FP_ENROLL_IDENTIFY that is no longer used
- finally use fpi_ssm_next_state instead of explicitly jumping to
FP_ENROLL_CREATE
Additionally, all types/functions/variables referring to "enroll_init"
used for FP_ENROLL_CREATE have been renamed to match "enroll_create".
All other states use similar name matching.
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
After the driver internal duplicate check had been removed in
46669e9f53, all templates were saved with
an all-zeroes template ID.
By going through FP_ENROLL_CREATE before starting to capture, the
template ID returned from the device is taken into account again.
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Drop if statement that retrieves internal ssm->error.
"error" is already a copied ssm->error, so it makes no sense to return
internal copy which will be freed when ssm is marked as done.
Fixes#526
That's a defined variable that may be there or not, and currently we
warn with:
- fpi-image.c:29:5: warning: "HAVE_PIXMAN" is not defined, evaluates to 0
This these functions are not really needed by anything else than
FpDevice, so move them back to the cpp file, so that we don't expose
them in the private library, given that we don't need them
Ensure that the memory that we're going to populate via USB transfer is
initialized, otherwise valgrind may complain about (even if that's not
really an issue).
At every action we update the device temperature, and this can
potentially lead to a failure, if the temperature is too hot.
However in such case we were failing a task that we had just stolen,
causing an error, tasks never returning and the device was left in an
undefined state.
So, just return early in case temperature is too hot, as we don't really
need to have the current task or action set at this point because
there's no active action to cancel yet.
This was causing random errors when running tests under valgrind
