If we fail when setting the scanned image to a print, we'll have a fatal
error, in such case we can terminate the current action and deactivate the
device.
In some cases nbim's get_minutiae returns no minutiae without providing an
error code, and if this happens we would crash in the task callback function
as we would try to deference the data->minutiae pointer.
Related to: #251
If the image height is less than the sensor horizontal resolution, then
return a retry error rather than trying to submit the image for further
processing.
Related to: #251
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
The unittest_parser script would try to import FPrint gi module, but it
would fail as per the fact that none is installed yet, so make sure that
we don't load any FPrint module until we try to actually run the tests
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
To avoid conflicts with previous libfprint version and make sure that the
target version is the correct one (plus to allow parallel install in some
distros), let's use a versioned naming for the library keeping the abi
version in sync.
Fixes#223
When quickly scanning a finger with the synaptic driver, it may wait forever
for finger removal even if this has already happened.
In fact we don't take care of the finger status when reporting the
verification.
To avoid this, add a function that delays the completion of the verification
until the finger removal if the finger is on sensor, otherwise it just
performs it.
Fixes#228
Remove the never-used cmd_complete_data value and the repetition of
cmd_complete_error.
In fact now as per the fpi_device_verify_report() usage, we already pass
the match information to the device, such as the error and it will be
they will be used on completion if needed.
This allows to simplify cmd_ssm_done() as well.
In some cases we want to complete the verification after that the finger has
been removed, but we still need to promptly report the match state otherwise
fpi-device will complain about, and will eventually cause a match error
instead that reporting a non-match:
synaptics: Finger is now on the sensor
synaptics: Received message with 0 sequence number 0x91, ignoring!
synaptics: interrupt transfer done
synaptics: delaying match failure until after finger removal!
synaptics: interrupt transfer done
device: Driver reported successful verify complete but did not report the
result earlier. Reporting error instead
libfprint: Failed to verify print: An unspecified error occured!
Fixes#227
Promptly show the match/no-match result in the match callback instead of
waiting the verification process to be finished.
Also exit in case of an hard error, while permit to try again in case of a
retry error.
This was added as alias to the error check, but given we're passing to the
callback both the error and the match itself, we can just avoid adding an
extra parameter that could be confusing (as may imply that the matching
happened).
Also clarify the documentation and ensure that the match value is properly
set in tests.
We might want to iterate through the supported fingers values, to do that we
were hardcoding FP_FINGER_LEFT_THUMB and FP_FINGER_RIGHT_LITTLE as first and
last fingers.
Not that we'd ever get more fingers (unless some weird radiation would do
the job), but it's logically nicer to read than random hardcoded values.
We're using some new features, and we may use more in future so better to
bump the version to the minimum required than look back given we're still
unstable.
Fixes#204
Don't make headers inclusions dependent on each others, given that FpiSsm
depends on FpiUsbTransfer and vice-versa, so fix the dependency cycle by
using forwarded declarations.
While timeout was already cleared for parent, we didn't properly delete the
cancellable.
Although we'd warn anyways when starting the SSM, is still better to clear
any delayed action also for the sub-SSM
Since tests depending on the fake device don't depend on virtual-image
driver anymore, let's change the way we organize the things, by putting
everything in the test lib, but enabling unit-tests depending on what they
depend on.
Use the virtual image device as base for now, while the new setup allows
to create easily fake device drivers without including the driver in
libfprint itself and test all the fpi_device functionalities.
In order to be able to test the private device code (used by drivers) we
need to have that split a part in a different .c file so that we can compile
it alone and link with it both the shared library and the test executables.
Redefine fp_image_device_get_instance_private for private usage, not to move
the private struct as part of FpDevice.
In order to be able to test the private device code (used by drivers) we
need to have that split a part in a different .c file so that we can compile
it alone and link with it both the shared library and the test executables.
Redefine fp_device_get_instance_private for private usage, not to move
the private struct as part of FpDevice.
A Fp-device use an union to track the handle to the lower-level device, and
the value depends on the object type.
So in case of using a virtual device, the priv->usb_device location matches
the priv->virtual_env string location, and thus we'd end up unreffing a
string location as it was a GObject, while we'd leak the string.
To avoid such errors, instead of just checking the device type when we
finalize the device, let's just use different pointers to avoid other
possible clashes.
