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
Also unset the private library if set and make libfprint to only link
with the tod one.
This fixes the issue we had with wrong symbols shared by multiple
libraries
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
We have an issue where some symbols are exposed by both the tod library
and the public one, and this may lead to big issues like GType's being
defined multiple times.
So add a test checking whether this is working
See: 3v1n0/libfprint#1
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
To compute the device ports we walked up through the devices using
g_usb_device_get_parent(), but this is supposed to return a device with
transfer full, so we need to unref it when done with it.
To handle this nicely, use a mixture of autopointer's and g_set_object
to ensure we're doing the right thing when passing the ownership around.
It's suggested to use g_memdup2 everywhere, but since we've a max-glib
version set we'd get a "deprecation" warning.
Avoid it this by re-defininig it through a macro in both cases.
Fix possible race which would happen when freeing the devices array
before cancelling the initialisation:
(/builds/libfprint/libfprint/_build/tests/test-fp-context:1449): GLib-CRITICAL **: 14:00:19.640: g_ptr_array_add: assertion 'rarray' failed
It may cause initializing a type twice in some cases, and thus some
hard-locking, let's just avoid it since we don't care about full debug
strings here.
Newer fprintd supports duplicate-detection, this implies sending to the
device an empty prints gallery, expecting the device to give us a
matched print against its storage.
In case the device has no storage we're doing this anyway, but goodix
doesn't handle this properly, so let's just ignore the case if no prints
are passed.
Drop re-definition of stderr. There's no need for this anywhere
(including glibc). This breaks in particular on musl because
stderr (and stdin) are both const, and macros unlike in glibc.
Bug: https://bugs.gentoo.org/853811
When opening the device, query the stored prints. This should usually
always succeed (and it should be fast). If it fails, then we are very
likely dealing with a corrupted template storage on the device. In that
case, emit the command to clear the storage in order to reset the device
and get it back into a usable state.
It is completely fine for a capture to have a low quality or fail. No
need to warn about this. Main reason to remove it though is so that
recordings that contain such a message do not trigger a failure.
Marco Trevisan (Treviño)