v1.94.5
* New driver: fpcmoc, supporting various FPC MOC Fingerprint Sensors
* goodixmoc: New PIDs 0x6014, 0x6094, 0x631C, 0x634C, 0x6384, 0x659A.
* goodixmoc: Support resetting device on firmware failure due to corrupted DB.
* elanmoc: New PIDs 0x0c88, 0x0c8c, 0x0c8d.
* synaptics: New PID 0x0104.
* upektc: New PID 0x2017.
* Fixed various memory leaks
* More tests
Git-EVTag-v0-SHA512: a36e4b627ffc830a78932266119b73e53921965990bd1b6cae6fd8d166b1b8e62f5a538151a74b82a2a2d83a4ab7399ed17cb2bef39441f881a38a24252e4efa
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.
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.
Marco Trevisan (Treviño)