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.
Recompile tod drivers using libfprint-tod-test-drivers project [1] so
that we don't have to reorder the private driver structure, plus use a
versioned driver ID and parse it to check whether a feature is supported
for such TOD test driver.
https://gitlab.freedesktop.org/3v1n0/libfprint-tod-test-drivers
Tag 1.94.0
Git-EVTag-v0-SHA512: 7cf9d7defb02433140f575589099569a5848ab34e8ecb0a4a90bb3c9eb1c228a16438afe1b23c381b59c1506f189a845752fead3dbd3c1c11f686cf47302cb1b
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.
Tag 1.90.6
Git-EVTag-v0-SHA512: 1cca84a89332a674d822476e587e1d9f30dc11bfff13724548ec0be66ab32f910fb5e7a7c9403c9a813538fdd9e86661105af8e2a4865b0b30d301601c7bddab
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 can ensure better that it works as expected repeating all the device
tests for it too.
The nice part is that we can just do this by re-defininig its GType as
the gtype of the loaded driver.
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.
Benjamin Berg