Cancelling an operation does allow the driver to do perform async ops
at the moment, but rather we are supposed to just send the the cancel
commands while another action may running.
So we should handle this as part of the SSM final stage, if cancellation
happened.
Add IDENTIFY_SEND_CANCEL_RESULT state to send cancel command
after identify/verify completes, triggering firmware template update.
Implement cancel() callback for enroll and identify/verify cancellation.
Updated umockdev test data to cover the new flow.
When a USB transfer is cancelled, actual_length is set to -1. This
gets implicitly cast to gsize (unsigned) in log_transfer(), resulting
in a huge length passed to fp_dbg_hex_dump_data() and causing a
segfault.
Only dump data when the length is within valid bounds.
There is no need for them to be writable and with the previous commit
this change will also not result in any compiler warnings. Simply change
all of the static definitions to be static const.
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
The function only uses the passed command as a const buffer and makes a
copy immediately. As such, there is also no need for a destroy callback
as the caller can simply clean up afterwards.
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
While most of commands should run separated, others such as cancellation
can run concurrently so we cannot share command data in the device
structure, but it has to be rather per command.
Move it there
The driver relied on a running finger-detection or capture callback to
observe the deactivating flag and call complete_deactivation(). When the
async loop was broken by a session error from a terminal callback (such
as capture_sm_complete), no further iteration was left to notice the
flag, so the deactivation never completed.
Rather than scatter complete_deactivation() calls after every
fpi_image_device_session_error(), track whether an operation is actually
pending with an "active" flag and let dev_deactivate() complete the
request itself when nothing is in flight.
This keeps the deactivation lifecycle owned by dev_deactivate.
When tapping on the sensor rather than swiping through it, super RSR will
drop slices with 0-3 pixels of Y motion. In such case, self->strips_len is
zero and causing protocol error. Handle such cases by calling for a re-scan.
Closes: https://gitlab.freedesktop.org/libfprint/libfprint/-/work_items/786
Assisted-by: DeepSeek:deepseek-v4-pro-preview
Signed-off-by: Shengyu Qu <wiagn@4d2.org>
In some cases, the driver generates error, but complete_deactivation() is not
called after calling fpi_image_device_session_error(). In this case, fprintd
would be waiting for fpi_image_device_deactivate_complete() forever. Fix by
adding calls for complete_deactivation();
Closes: https://gitlab.freedesktop.org/libfprint/libfprint/-/work_items/786
Assisted-by: DeepSeek:deepseek-v4-pro-preview
Signed-off-by: Shengyu Qu <wiagn@4d2.org>
We cannot assume that two NBIS prints are matching without going through
proper NBIS checks, so we cannot do a check on the scanned print without
an extra thread, which is rather an overkill.
So let's just do the check for prints we can actually compare (raw ones
for now)
We used to enroll and verify always the same prints, which made
generating the very same enrolled prints, that simplifies the libfprint
matching.
To make this a bit more real, let's apply some transformations to the
print images before sending them each time
