Drop if statement that retrieves internal ssm->error.
"error" is already a copied ssm->error, so it makes no sense to return
internal copy which will be freed when ssm is marked as done.
Fixes#526
That's a defined variable that may be there or not, and currently we
warn with:
- fpi-image.c:29:5: warning: "HAVE_PIXMAN" is not defined, evaluates to 0
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
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
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.
