there is no specific API for report finger status,
finger needed status is set when captrue sample cmd send, once cmd receive correct,
finger is pressing on sensor.
Found by coverity. While quite bad in theory, proper safeguards are in
place, so it will only result in a g_return_val_if_fail to be hit rather
than causing more severe side effects.
We used to return early in the case where the print matched in order to
report the result more quickly. However, with the early reporting
mechanism and the fprintd side implementation of it, this is not
necessary anymore.
As such, only stop the "verify" and "identify" operations when the
finger is removed (or the operation is cancelled, which is actually what
will happen currently).
It is easier (and more correct) to create a new print from the reported
data and match that against the prints in the gallery.
We continue to return NULL during verify as we cannot provide any
additional information in that case.
2020-12-04 10:30:09 @bigon:
Trevinho: I just found an old mail from Odyx/Didier asking me to remove him
from the uploaders, maybe you could do that and add yourself if you plan to
maintain the two packages in debian.
NBIS just does weird things and while the array-parameter warning is
easy to fix, the other is not trivial. So disable these warnings so that
we can still build using newer GCC versions.
Tag 1.90.6
Git-EVTag-v0-SHA512: 1cca84a89332a674d822476e587e1d9f30dc11bfff13724548ec0be66ab32f910fb5e7a7c9403c9a813538fdd9e86661105af8e2a4865b0b30d301601c7bddab
NBIS just does weird things and while the array-parameter warning is
easy to fix, the other is not trivial. So disable these warnings so that
we can still build using newer GCC versions.
The gallery needs to be copied, as such we must do a deep comparison
instead of comparing the pointers. We also can't do the comparison
afterwards, as the gallery is owned by the operation and that operation
is finished already.
This function was always documented to return a sunk reference, but it
did not do so. This change is technically backward incompatible.
However, it only has an effect if anything is doing a g_object_ref_sink.
Which may happen inside libfprint itself. With the change, most API
users (including fprintd) are fixed to do refcounting correctly. Any API
user which worked around this will have a memory leak now.
That is not ideal, but it is not really that bad overall. And returning
a floating reference for FpPrint creation was a bad idea in the first
place. And it really only makes sense for fp_print_new as the only
(public) use case is to create the template for enrollment.
Benjamin Berg