The slack of 250ms wasn't enough on loaded CI systems, causing frequent
flaky failures (e.g. 2276ms actual vs 2250ms limit, or 2294ms vs 2250ms).
Double the slacks to 500ms for the 2s transitions and 1000ms for the
5s transition to absorb system load noise while still catching real
timing regressions.
We're still going into the device in this case because technically the
identify operation may still return a print, although never a match of
course.
Adding tests so that we are not tempted to modify the behavior of the
identify function to return an error on prints->len == 0 or to just not
call the driver on such case.
Devices can scan even without a match, but if they do match a print then
they must match.
Ensure this in code to prevent drivers to return inconsistent data.
In case a device has not support for verification through an explicit
verify function, the verification can still be implemented using
identification with a gallery of a single print.
In fact that's what most of drivers these days do it, so let's just
avoid to them to handle this duplication unless a driver has really some
specific commands to do it.
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
The code is correct, but gcc thinks the pointer is still NULL after the
call. As obvious workaround don't seem to work, just disable the warning
for now.
* Allow FPI_PRINT_NBIS to be extended rather than overridden if a user
supplies an existing FpPrint template with data;
* Prints will only be extended if a device has the required feature.
For image-based devices this feature is added by default since they
typically do not have storage (this can be overridden at the child
class level).
Extending an existing FpPrint requires passing a template print with
existing data during the enrollment process. This is done because the
caller is responsible for maintaining the fingerprint database and doing
the necessary deserialization operations if needed. The existing
example program is updated to show how to do that.
This will allow libfprint to cancel operations internally in the future.
If the internal cancellation method is used, then the private
current_cancellation_reason variable must be set to the GError. This
error will be returned when set.
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.
It can be convenient for device users to check what it supports, without
having multiple functions to check each single feature.
So expose this and add tests.
We always assumed a device can verify, but nothing prevents from having
a device that only can identify or capture.
So, given that we've more fine grained checks, let's stop the task if
this is the case.
Allows drivers to define more fine grained features for devices, not
strictly depending on assumptions we can make depending on the
implemented vfuncs.
We keep this per class but could be in theory moved to each instance.
In any case, added an utility function to initialize it in the way we
can ensure that we've a consistent way for setting them across all the
devices.
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.
We require the close call, but as the underlying transport layer is
gone, it will generally just return an error.
In principle, it makes sense to think of close as a function that always
succeeds (i.e. it makes no sense to try again). Should the device be in
a bad state, then a subsequent open() will simply fail.
During verify/identify complete we replace the error pointer that the driver
returned with another error we created, after clearing that one.
However, when we initialize a new error the compiler may reuse the same
allocation of the cleared one, and this might lead to a test failure.
So, don't be so fragile and ignore the pointer check
Devices with no storage don't allow listing prints, and if we try to do
that, we'd end up in trying to call a NULL function pointer, causing a crash
So always check if the device has storage before calling the list vfunc, and
if we fail, return an error.
Include an unit-test to verify this situation
We are already using a number of defines and autoptrs from newer GLib
releases. Add the appropriate compatibility defines rather than removing
the corresponding code.
Closes: #222
The g_object_new call had a NULL argument for a property. This meant
that the compiler could not warn about the lack of NULL termination for
the argument list.
Add the missing NULL termination.
