task_ssm_done cleared task_ssm before calling maybe_cancel, so
identify_cancel_ssm_done couldn't tell whether the identify already
completed or was cancelled. Use fpi_device_action_is_cancelled()
and skip the duplicate identify_complete call in IDENTIFY_COMPLETE
state when cancelled, letting the cancel flow handle completion.
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
The device may report a number of enrolled fingers but this value is not
checked against the data, so let's do it to prevent an overflow
Reported by: Keith Linneman (LinnemanLabs)
The message parser trusted the device-supplied payload length without
checking it against the number of bytes actually received.
A malicious or malfunctioning reader could thus drive an out-of-bounds
read past the received buffer.
Reject a header whose declared payload would extend past the received
data (and a too-short header).
Reported by: Keith Linneman (LinnemanLabs)
The frame length and the offset (which depends on the device-supplied
frame type) are derived from device bytes, so validate both the source
read (against the response buffer) and the destination write (against
the image buffer) before copying.
A malicious or malfunctioning device could otherwise drive a negative
(huge once unsigned) or out-of-bounds length.
Note: the response is reassembled across several USB transfers, so the
bound here is the response buffer capacity rather than a single
transfer's actual_length.
Reported by: Keith Linneman (LinnemanLabs)
num_lines comes from the device for each block and is summed into
the source row index (r) and destination byte offset (to).
Neither the per-block value nor the running totals are otherwise bound,
so a malicious device could drive the copy past the source
(IMAGE_HEIGHT rows) or destination buffer.
Reported by: Keith Linneman (LinnemanLabs)
The SSM error is stolen and then we pass to the resume/suspend callback
potentially leading to a double-free.
So copy it before re-using it.
Reported by: Keith Linneman (LinnemanLabs)
fp_device_finalize calls g_slist_free_full() to destroy any still-pending
timeout sources.
Each g_source_destroy call triggers timeout_finalize, which tries to
remove the current source from the sources list.
This may lead to a double-free, as iterating over a list deleting items
is not supported.
Add a regression test that adds a timeout with a long delay and immediately
finalizes the device while the timeout is still pending.
The slack of 250ms wasn't enough on loaded CI systems, causing frequent
flaky failures (e.g. 2276ms actual vs 2250ms limit, or 2294ms vs 2250ms).
Double the slacks to 500ms for the 2s transitions and 1000ms for the
5s transition to absorb system load noise while still catching real
timing regressions.
We're still going into the device in this case because technically the
identify operation may still return a print, although never a match of
course.
Adding tests so that we are not tempted to modify the behavior of the
identify function to return an error on prints->len == 0 or to just not
call the driver on such case.
Devices can scan even without a match, but if they do match a print then
they must match.
Ensure this in code to prevent drivers to return inconsistent data.
As per recent changes, drivers can just avoid implementing verify vfunc
unless the driver has specific commands to do it.
So let's just drop the duplicated code in drivers that have the very
same code path for both identification and verification.
In case a device has not support for verification through an explicit
verify function, the verification can still be implemented using
identification with a gallery of a single print.
In fact that's what most of drivers these days do it, so let's just
avoid to them to handle this duplication unless a driver has really some
specific commands to do it.
Same MOC protocol family as the already-supported 27c6:6384/631C.
Verified against real hardware: open, enroll, verify, identify and
delete all succeed. Dell's own driver .inf for this PID (extracted
from Goodix-Fingerprint-Sensor-Driver_T2VK3_WIN64_40.10.1.100_A05_01.EXE)
confirms it uses the plain (non-SecureFingerprint) MOC protocol.
If the reader does not respond, currently the plugin segfaults.
The error should be handled gracefully.
With this change, an error is printed instead of crashing:
failed to claim device:
GDBus.Error:net.reactivated.Fprint.Error.Internal:
Open failed with error: Can't get response!!
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Add USB PID 0x2020 (NB-2020-U) to the nb1010 driver's id_table.
The NB-2020-U is an embedded variant of the NB-1010-U using an
identical sensor die (confirmed by independent teardown reports from
System Plus Consulting/Yole Group). USB endpoint layout, command
protocol and image format are identical between both devices.
Tested on a Fujitsu notebook with integrated NB-2020-U reader
(USB ID 298d:2020): device enumeration, finger detection polling
and image capture all work correctly with the existing nb1010
driver code.
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.com>
In test mode, dynamically load libraries in well known locations that can
allow to override the libfprint behavior.
It would still be possible to potentially inject code by replicating the
distro build directory and adding a library there, but if one is able to
access there, they would already be able to access any path.
Plus the env variable check is still there, so again they would need to
be able to change the fprintd environment
Rather than just do it in production if set, make it more difficult to
potentially inject the test mode.
So rely on a weak definition of fpi_device_emulation_mode_enabled() that
can be only set externally
Drivers may do some adjustments in test mode, initially we wanted to
reduce this to the minimum but the usage of `FP_DEVICE_EMULATION`
exploded, so move this instead into a properly defined variable that:
- Uses GLib compiler optimizations
- Is read just once per process
- Cannot be misused
As per commit bad930503c the test data is way bigger than it used to
be, so the test duration is longer.
Thus increase the timeout not to have failures
DT_RUNPATH is intentionally searched after $LD_LIBRARY_PATH.
-Wl,--disable-new-dtags switches to the old DT_RPATH tag, which is searched
before $LD_LIBRARY_PATH. So the embedded paths in the build binary will now
win over whatever is in the environment.
Not breaking builds.
Use bounded uid strings for template-info handling.
- stop printing fixed-size device buffers with raw %s
- use g_strndup(..., TEMPLATE_UID_SIZE) before logging tpl_info.uid
- compare delete target uid against the bounded copy
- log handshake response as bytes instead of %s
This avoids over-read/invalid-UTF8 issues when unknown/corrupted entries
contain non-NUL or 0xff-filled uid data.
The Elan 04f3:0c58 sensor returns 0xaf during capture which indicates
finger removed or sensor busy. Also 0x00 can occur meaning not ready.
These responses should trigger a retry instead of failing.
To avoid changing behavior for other Elan devices, limit the new retry
logic to the 0x0c58 device type and add a small 10ms delay between
retries.
Additionally, increase calibration attempts from 10 to 30 for 0x0c58
as this sensor needs more time to complete calibration.
Source: https://gitlab.freedesktop.org/libfprint/libfprint/-/work_items/763
Signed-off-by: lichenggang <lichenggang@uniontech.com>
Co-Authored-By: Marco Trevisan (Treviño) <mail@3v1n0.net>
Add support for the SecuGen Hamster Pro 20 (1162:2200), a 500 DPI
press-type optical scanner built around the SIDO020A sensor.
The protocol was reverse-engineered from USB packet captures. The
sensor is configured over I2C-tunneled vendor control transfers and
streams 956x688 raw frames over the bulk endpoint, read in 64KB
chunks so the standard pcap-based test tooling can record full
frames (the kernel usbmon interface truncates single URBs at
ring_size/5). Frames are processed with band compensation, an
edge-aware unsharp mask, a fixed-point bilinear downsample to
300x400, flat-field blending and directional sharpening, driven by
per-device factory calibration data read from the device firmware.
The fixed-point pipeline keeps the output bit-identical across
compilers and architectures for the image comparison test.
The sensor has no proximity hardware and its GET_STATUS request
always returns zeros, so finger presence is detected by polling
preview frames and comparing the mean brightness of the central
region against a calibration background frame.
Includes a umockdev capture/replay test with a reference image.
Closes: https://gitlab.freedesktop.org/libfprint/libfprint/-/work_items/353
Fixes the CI test_scan_build
libfprint/drivers/fpcmoc/fpc.c:275 — [deadcode.DeadStores]
warning: Value stored to 'data' during its initialization is never read
CommandData *data = fpi_ssm_get_data (ssm);
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Re-record the umockdev USB capture to include the new
GOODIX_VERIFY_WAIT_FINGER_UP state's USB exchanges during
verify and identify operations.
Captured on a Goodix MOC sensor (27c6:609c, Framework Laptop 13)
with FP_DEVICE_EMULATION=1 as required by the test framework.
The goodixmoc driver's verify state machine was missing a
WAIT_FINGER_UP state between IDENTIFY and PWR_BTN_SHIELD_OFF.
After the sensor reported a match/no-match result, the driver
immediately completed the verify operation without waiting for
the finger to be lifted from the sensor.
This caused problems when fprintd retried verification after a
no-match: the finger was still on the sensor, so the same
(wrong) finger was scanned again instantly. On fast match-on-chip
readers, all retry attempts could be exhausted in under a second,
giving the user no time to reposition their finger.
Add GOODIX_VERIFY_WAIT_FINGER_UP to the verify state machine,
mirroring the existing GOODIX_ENROLL_WAIT_FINGER_UP in the
enroll flow. The new state sends MOC_CMD0_FINGER_MODE /
MOC_CMD1_SET_FINGER_UP to the sensor and waits for the finger
to be removed before advancing to PWR_BTN_SHIELD_OFF.
The callback handles the same cases as the enroll equivalent:
- Timeout (5s): retry the finger-up wait
- Protocol error: fail the SSM
- Success: clear FINGER_STATUS_PRESENT and advance
Link: https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/209
This FPreader was found on Minisforum X1 Pro MiniPC, and it is
listed by lsusb as "Generic Realtek USB2.0 Finger Print Bridge".
Though the VID is not the same as the well-known "0bda", we can
confirm it's from Realtek by analyzing Windows version driver.
Signed-off-by: Ryan Wong <colorfulshark@gmail.com>
If the button shield command cannot be executed due to an underlying
error then resp is NULL. Avoid the crash by adding the appropriate
check.
Closes: #694
../libfprint/drivers/uru4000.c:743:35: runtime error: left shift of 138 by 24
places cannot be represented in type 'int'
#0 0x7fa3e696e06d in imaging_run_state ../libfprint/drivers/uru4000.c:743
#1 0x7fa3e6a366f6 in __ssm_call_handler ../libfprint/fpi-ssm.c:254
#2 0x7fa3e6a38cc8 in fpi_ssm_next_state ../libfprint/fpi-ssm.c:465
#3 0x7fa3e696bd07 in sm_read_reg_cb ../libfprint/drivers/uru4000.c:515
#4 0x7fa3e6a3db74 in transfer_finish_cb ../libfprint/fpi-usb-transfer.c:352
#5 0x7fa3ed9b9862 in g_task_return_now ../../glib/gio/gtask.c:1363
#6 0x7fa3ed9b989c in complete_in_idle_cb ../../glib/gio/gtask.c:1377
#7 0x7fa3ede4a70b in g_main_dispatch ../../glib/glib/gmain.c:3373
#8 0x7fa3ede4c8de in g_main_context_dispatch_unlocked ../../glib/glib/gmain.c:4224
#9 0x7fa3ede4c8de in g_main_context_iterate_unlocked ../../glib/glib/gmain.c:4289
#10 0x7fa3ede4cfef in g_main_context_iteration ../../glib/glib/gmain.c:4354
#11 0x7fa3e68d4a1b in fp_device_capture_sync ../libfprint/fp-device.c:2048
We had some read issues, so let's just use the safer reader that
makes things cleaner too
../libfprint/drivers/goodixmoc/goodix_proto.c:418:42: runtime error:
load of misaligned address 0x0000115ced29 for type 'uint16_t', which
requires 2 byte alignment
0x0000115ced29: note: pointer points here
00 c0 3f 00 21 64 1c 00 00 00 00 64 00 43 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
#0 0x7f974ff9e868 in gx_proto_parse_body ../libfprint/drivers/goodixmoc/goodix_proto.c:418
#1 0x7f974ff8ec79 in fp_cmd_receive_cb ../libfprint/drivers/goodixmoc/goodix.c:185
#2 0x7f975003ca0c in transfer_finish_cb ../libfprint/fpi-usb-transfer.c:352
#3 0x7f9756e57862 in g_task_return_now ../../glib/gio/gtask.c:1363
#4 0x7f9756e5789c in complete_in_idle_cb ../../glib/gio/gtask.c:1377
#5 0x7f97577f070b in g_main_dispatch ../../glib/glib/gmain.c:3373
#6 0x7f97577f28de in g_main_context_dispatch_unlocked ../../glib/glib/gmain.c:4224
#7 0x7f97577f28de in g_main_context_iterate_unlocked ../../glib/glib/gmain.c:4289
#8 0x7f97577f2fef in g_main_context_iteration ../../glib/glib/gmain.c:4354
#9 0x7f974fed4656 in fp_device_verify_sync ../libfprint/fp-device.c:1976
This is was leading to a potential error due to misaligned memory:
../libfprint/drivers/goodixmoc/goodix.c:167:20: runtime error: load of
misaligned address 0x00001165c989 for type 'uint32_t', which requires 4 byte
alignment
0x00001165c989: note: pointer points here
00 00 00 00 0a ac b3 09 00 00 00 00 00 00 55 53 42 00 00 00 00 00 56 42 53 00 00 00 00 00 30 30
^
#0 0x7ff3ba98d190 in fp_cmd_receive_cb ../libfprint/drivers/goodixmoc/goodix.c:167
#1 0x7ff3baa3b235 in transfer_finish_cb ../libfprint/fpi-usb-transfer.c:352
#2 0x7ff3c18ca862 in g_task_return_now ../../glib/gio/gtask.c:1363
#3 0x7ff3c18ca89c in complete_in_idle_cb ../../glib/gio/gtask.c:1377
#4 0x7ff3c228470b in g_main_dispatch ../../glib/glib/gmain.c:3373
#5 0x7ff3c22868de in g_main_context_dispatch_unlocked ../../glib/glib/gmain.c:4224
#6 0x7ff3c22868de in g_main_context_iterate_unlocked ../../glib/glib/gmain.c:4289
#7 0x7ff3c2286fef in g_main_context_iteration ../../glib/glib/gmain.c:4354
#8 0x7ff3ba8d2fe5 in fp_device_open_sync ../libfprint/fp-device.c:1874
../libfprint/drivers/goodixmoc/goodix_proto.c:214:5: runtime error: null pointer passed as argument 2, which is declared to never be null
#0 0x7f378839c3e5 in gx_proto_build_package ../libfprint/drivers/goodixmoc/goodix_proto.c:214
#1 0x7f378838fd9e in alloc_cmd_transfer ../libfprint/drivers/goodixmoc/goodix.c:309
#2 0x7f378838ffe4 in goodix_sensor_cmd ../libfprint/drivers/goodixmoc/goodix.c:336
#3 0x7f378839a778 in gx_fp_template_delete_all ../libfprint/drivers/goodixmoc/goodix.c:1602
#4 0x7f37882d3d59 in fp_device_clear_storage ../libfprint/fp-device.c:1820
#5 0x7f37882d50af in fp_device_clear_storage_sync ../libfprint/fp-device.c:2132
../libfprint/drivers/goodixmoc/goodix_proto.c:111:26: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
#0 0x7f6776799c2e in reflect ../libfprint/drivers/goodixmoc/goodix_proto.c:111
#1 0x7f677679a0f3 in crc32_final ../libfprint/drivers/goodixmoc/goodix_proto.c:147
#2 0x7f677679a3ee in gx_proto_crc32_calc ../libfprint/drivers/goodixmoc/goodix_proto.c:164
#3 0x7f677679d7aa in gx_proto_init_sensor_config ../libfprint/drivers/goodixmoc/goodix_proto.c:464
#4 0x7f6776797b40 in gx_fp_init ../libfprint/drivers/goodixmoc/goodix.c:1415
#5 0x7f67766cc56e in fp_device_open ../libfprint/fp-device.c:866
#6 0x7f67766d2fd4 in fp_device_open_sync ../libfprint/fp-device.c:1872
../libfprint/drivers/synaptics/bmkt_message.c:260:5: runtime error: null pointer passed as argument 2, which is declared to never be null
#0 0x7fd21f154592 in bmkt_compose_message ../libfprint/drivers/synaptics/bmkt_message.c:260
#1 0x7fd21f14596c in synaptics_sensor_cmd ../libfprint/drivers/synaptics/synaptics.c:417
#2 0x7fd21f14d93f in dev_probe ../libfprint/drivers/synaptics/synaptics.c:1329
#3 0x7fd21f0ca61d in device_idle_probe_cb ../libfprint/fp-device.c:375
#4 0x7fd21f21a431 in timeout_dispatch ../libfprint/fpi-device.c:336
#5 0x7fd2269cf70b in g_main_dispatch ../../glib/glib/gmain.c:3373
#6 0x7fd2269d18de in g_main_context_dispatch_unlocked ../../glib/glib/gmain.c:4224
#7 0x7fd2269d18de in g_main_context_iterate_unlocked ../../glib/glib/gmain.c:4289
#8 0x7fd2269d1fef in g_main_context_iteration ../../glib/glib/gmain.c:4354
#9 0x7fd21f0c5a85 in fp_context_enumerate ../libfprint/fp-context.c:575
When memory sanitizers are set, tests may fail because we are indirectly
LD_PRELOAD'ing (through umockdev). While we could ensure that sanitizer
libraries are loaded first, it's just something we don't care because we
don't want to test the launcher wrappers themselves.
So, let's just ignore the link order and live with it
Drop usage of NSS library now that openssl >= 3.0 has not anymore any
license incompatibility.
OpenSSL will provide us a better ground for further developments and
it's also the preferred crypto library by most distros these days
Valgrind tests may be slow, leading the devices to be considered hot.
We don't disable this for other tests, since we may still want to be
sure that the logic is fine for normal usage
We may send an image when not waiting it, leading to a failure:
libfprint-image_device-DEBUG: 00:55:29.669: Image device internal state change
from FPI_IMAGE_DEVICE_STATE_DEACTIVATING to FPI_IMAGE_DEVICE_STATE_INACTIVE
libfprint-image-DEBUG: 00:55:31.861: Minutiae scan completed in 2.204906 secs
libfprint-print-DEBUG: 00:55:56.902: score 1093/40
libfprint-device-DEBUG: 00:55:56.902: Device reported verify result
libfprint-device-DEBUG: 00:55:56.902: Device reported verify completion
libfprint-device-DEBUG: 00:55:56.903: Updated temperature model after 27.26
seconds, ratio 0.69 -> 0.73, active 1 -> 1,
FP_TEMPERATURE_WARM -> FP_TEMPERATURE_HOT
libfprint-device-DEBUG: 00:55:56.906: Completing action
FPI_DEVICE_ACTION_VERIFY in idle!
libfprint-device-DEBUG: 00:55:56.906: Updated temperature model after 0.00
seconds, ratio 0.73 -> 0.73, active 0 -> 0,
FP_TEMPERATURE_HOT -> FP_TEMPERATURE_HOT
libfprint-device-DEBUG: 00:55:56.910: Updated temperature model after 0.00
seconds, ratio 0.73 -> 0.73, active 1 -> 1,
FP_TEMPERATURE_HOT -> FP_TEMPERATURE_HOT
libfprint-device-DEBUG: 00:55:56.910: Updated temperature model after 0.00
seconds, ratio 0.73 -> 0.73, active 0 -> 0,
FP_TEMPERATURE_HOT -> FP_TEMPERATURE_HOT
libfprint-virtual_image-DEBUG: 00:55:56.912: image data: 0xc8f6c10
libfprint-device-DEBUG: 00:55:56.916: Device reported finger status change:
FP_FINGER_STATUS_PRESENT
libfprint-image_device-DEBUG: 00:55:56.917: Ignoring finger presence report as
the device is not active!
libfprint-image_device-CRITICAL **: 00:55:56.918:
fpi_image_device_image_captured: assertion
'priv->state == FPI_IMAGE_DEVICE_STATE_CAPTURE' failed
Doesn't build on other operating systems.
With auto-detection we don't have to manually select all other drivers.
Signed-off-by: Daniel Schaefer <dhs@frame.work>
For the custom enrollment,
if the number of immobile touches have reached the maximum,
we should treat this touch as normal (valid) and increase
the enrollment progress.
Since the driver seem to require a big-endian value it's just better
to use architecture native endianness to compute the check value and
eventually just convert to big endian as the chip wants.
GLib 2.68 is now more than 3 years old, so we can definitely start
using it without thinking too much.
This allows us to drop lots of compat code that we had around.
And like the previous commit tells us, it will also help us to have
more correct code around.
We had various cases in which we were using const pointers for
non constant data, and in fact we were allocating and free'ing
them.
So let's handle all these case properly, so that we won't have
newer GLib complaining at us!
In case of suspension we can't just cancel the operations but
also return when completed, and this may not happen immediately
if there are ongoing operations.
This is automagically handled by libfprint internals, but in order
to make it happen, we need to cancel the ongoing operations and then
mark it completed. libfprint will then wait for the task completion
before actually marking the device as suspended.
We need to ensure that we are not overwriting the instance transfer, so
that we can be sure that we are only doing one transfer at time.
Also we need to ensure that the ssm unsetting it, is the owner of it.
We need to ensure that we are not overwriting the instance SSM, so that
we can be sure that we are only doing one operation at time.
Also we need to ensure that the task unsetting it, is the owner of it.
On Chimera Linux, which uses FreeBSD's userland tools, the original call
fails with the following error:
mktemp: mkstemp failed on /tmp/libfprint-XXXXXX.hwdb: Invalid argument
Moving the X's to the end of the template passed to `mktemp` fixes the
error, and also works with GNU's `mktemp`.
We can just use a GTask to handle the detection while using the
finish function to process the results to the image, so that it
is more predictable when this happens and it does not depend on
a thread returning.
Also remove data duplication when possible, this class wasn't
fully safe anyway to be used concurrently, so there's no point
to copy data when not needed. Also added the hard constraint to
not proceed with minutiae detection if something else is already
doing this.
At the same time we can mark the task to finish early on
cancellation.
dnf doesn't seem to handle the plugin well in rawhide:
bash-5.2# dnf -y debuginfo-install glib2
Unknown argument "debuginfo-install" for command "dnf5".
Add "--help" for more information about the arguments.
The unplug tests assume that the device is removed from the context once
they run, however we may have left the device around in a removed state
causing other tests to fail.
So isolate them in a new class where we create context and device
instances every time we run a test case.
As suggested by @benzea, the following cleanup actions have been
performed:
- let case order match enroll states enum
- remove FP_ENROLL_IDENTIFY that is no longer used
- finally use fpi_ssm_next_state instead of explicitly jumping to
FP_ENROLL_CREATE
Additionally, all types/functions/variables referring to "enroll_init"
used for FP_ENROLL_CREATE have been renamed to match "enroll_create".
All other states use similar name matching.
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
After the driver internal duplicate check had been removed in
46669e9f53, all templates were saved with
an all-zeroes template ID.
By going through FP_ENROLL_CREATE before starting to capture, the
template ID returned from the device is taken into account again.
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
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
We used to ignore leaks, and we are ending up in having various of them,
so let's make valgrind to exit with error when using the valgrind test
setup (so in CI) to catch them better.
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
We ignored assertions happening on callbacks as they only raise
exceptions that does not stop the execution.
So ensure that this is happening in all the tests as synaptics was
doing already
Same as commit: be8888431
We ignored assertions happening on callbacks as they only raise
exceptions that does not stop the execution.
So ensure that this is happening in all the tests as synaptics was
doing already
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.
gitlab has coverage integration in MRs, but we need a cobertura
formatted XML files (each must be less than 10 MB) to show it, since
meson generates it already via gcovr, we can just inform gitlab about it
See https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Traceback (most recent call last):
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <module>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <genexpr>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^
ValueError: invalid literal for int() with base 10: b'g9049374\n'
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.
If we delayed the suspend(/resume) call, then the circumstances may have
changed. In particular, an active action may have completed already
which means that the driver handler should not be called anymore.
These delayed calls are pushed into the mainloop for consistency.
However, they should run immediately and not be delayed, as such, it
makes sense to run them at a higher priority.
This actually solves an issue inside the CI where an URB reply is played
back even though it should be cancelled by the client.
We re-aquire the critical section at the start of the callback, however,
it needs to be dropped again (or not taken) if the interrupt transfer is
resubmitted.
The kernel caches URBs to get descriptor values. Doing a reset before
starting the record ensures that we will see any descriptor reads in the
usbmon trace and can therefore correctly replay them (possibly not true
if they happen multiple times).
Having this should at least give us a slightly better idea about the
version that the user has installed. Obviously it is still not very
accurate (maybe a git hash would be good if available?), but it should
still be helpful overall.
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 internal storage of this device can get messed up by other operating
systems, so it's handy to be able to clear it.
I'm not 100% sure whether the commands I've sent to the device are
exactly what is supposed to be used (just a guess), but it did seem to
work, and it even fixed another issue I had.
The API should return the recognized print, even if none of the prints
given in the gallery (or the one passed to verify) matched. Without this
the garbage-collection of left-over prints does not work, causing issues
after reinstall.
Fixes: #444
In commit 5c28654d9 ("goodixmoc: Fix print template parsing") the length
check for the verify and duplicate check responses by requiring two
extra bytes at the end of the message.
There were also issues in other places where the length was not checked
correctly, including a scenario that could cause a read beyond the end
of the buffer.
Related: #444
* 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.
This ensures that we have processed all hotplug events before
considering enumeration to be complete. This is important due to USB
persist being turned off. At resume time, devices will disappear and
immediately re-appear. In this situatoin, enumerate could first see the
old state with a removed device resulting in it to not be discovered.
As a hotplug event is semingly emitted by the kernel immediately, we
can simply make sure to process this hotplug event before returning
from enumerate.
Closes: fprintd#119
The length is only a single byte in the transfer. However, the struct
had a uint32_t in that place, breaking the sizeof() calculation and
seemingly creating issues for certain lengths of user id strings (which
depend on the username).
Fix this by changing the type to uint8_t. Also add the initial 0x43
prefix byte and a byte of apparent padding that the struct contains.
Leave the two reserved bytes at the end, as they seem to actually have a
meaning (i.e. they are seemingly send in listings).
This effectively makes the struct one byte smaller, bringing it down to
127 bytes from 128 bytes.
Closes: #428, #404
While useful, there are advantages for this to be done by the
surrounding code (i.e. fprintd). As such, remove the identify stage from
the goodix driver and rely on fprintd doing it for us.
One can probably argue that neither solution is perfect. Ideally, we
would probably return the information required to delete the old print
to the upper stack and let the driver/device handle the duplicate
checking.
However, for now this works well. We may need to reconsider this if we
get devices that do the duplicate checking transparently and just throw
an enroll error.
NOTE: The driver did not report any progress for the identify step. As
such, the number of enroll steps reported by the device remain the same.
Closes: #415
It appears the kernel automatically "fixes" this mistake and it works.
the transfer in question is an interrupt transfer and should be submitted
as such. Do that in order to make things more correct and so that the
test can run.
This matches the expectation. i.e. we return no-match and we do not
return a scanned print as we don't have anything for it. If we did
indeed return a scanned print, then fprintd would try to delete it
during enroll and would then fail.
Note that we do *not* return a DATA_NOT_FOUND error in the storage
device if the print does not exist. This is because not all devices
support reporting this error. It is therefore more sensible to handle it
gracefully and expect test setups to set the error explicitly for
testing purposes.
The error may not be NULL, as such we need a second variable and then
we'll only forward any error from g_usb_device_release_interface if
there was none before.
We only allow suspending while we are in the interrupt transfer stage.
To suspend, we cancel the interrupt transfer and at resume time we
restart it.
This has been tested to work correctly on an X1 Carbon 8th Gen with
suspend mode set to "Windows 10" (i.e. S0ix [s2idle] and not S3 [suspend
to RAM]). With S3 suspend, the USB root hub appears to be turned off or
reset and the device will be unresponsive afterwards (if it returns). To
avoid issues, libfprint disables the "persist" mode in the kernel and
we'll see a new device instead after resume.
The assumption here is that in most cases, we will just cancel any
ongoing operation. However, if the device choses to implement
suspend/resume handling and it returns success, then operations will not
be cancelled.
Note that suspend/resume requests cannot be cancelled.
Closes: #256
Check if a device is too hot. If it is too hot already, refuse
operation. If it becomes too hot while an operation is ongoing, then
cancel the action and force a FP_DEVICE_ERROR_TOO_HOT return value.
Devices that are considered to never run hot will have FEATURE_ALWAYS_ON
set. If set, the UI can safely assume that it is fine to run fingerprint
authentication in the background without other user interaction.
Closes: #346
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.
This temperature model has three states:
* COLD
* WARM
* HOT
Device drivers can define the time it requires for the device to get HOT
and COLD. The underlying model assumes an exponential warming and
cooling process and enforces a cool-off time after the device has
reached the HOT state. This cool down period is however shorter than the
specified time in the driver.
The timeout is designed to continue commands automatically that are
common (e.g. opening the device). This doesn't really make sense for
scan commands, and removing the timeout enables test setups where user
interaction with the device may happen at arbitrary times.
One exception is device removal/unplug, in which case the timeout will
be added anyway.
Such an empty identify can be run by fprintd intentionally for duplicate
checking at the start of an enroll operation, which currently runs into
an error from the driver.
Avoid this by simply returning success immediately. This is fine, as
synaptics is only checking the explicitly passed list of prints rather
than using all available prints from the storage.
There are some large files, and in most setups (including CI runners) we
have multiple cores available. Use xargs to run multiple parallel
uncrustify jobs rather than one large one. Just hardcode 4 jobs and 4
files at the same time for now.
Pretty much all downstream distributions just enable all drivers anyway.
Also, it should work well enough, so it seems right to simply add
elanspi into the list of drivers that are enabled by default.
We were testing only for .ioctl files, but we may now have .pcap file
and ended up simply not running the synaptics test unless there was
still a .ioctl file present.
Simply remove the feature flag for the NO_LIST environment variable.
This also removes the IDENT variant for now as it has never been
implemented as described.
The new elanspi driver in particular needs a lot of ioctl's during the
test. On a normal machine, this would run quite quickly (less than 5s),
however, in busy CI environments this can take longer than 30s, causing
timeouts currently.
Increase the timeout from 10s to 15s. For CI this means the timeout now
is 45s which is hopefully enough.
During startup, we'd always get:
(fprintd:151125): libfprint-uru4000-WARNING **: 12:16:56.724: ignoring unexpected interrupt 56aa
But we actually know what this interrupt is, and it's not unexpected, as
it tells us that the reader is now powered on.
The new features will be added in 0.16, so match against that. Also,
match against CI_PROJECT_NAME to detect our CI environment (and assume
that umockdev has been patched to the point of supporting all tests).
If the tile in question was hanging over the left edge we would not be
copying the full available width. Fix this and change the test to catch
the error condition (by forcing a too small image and overlap both
ways).
Simplify the code by only selecting the starting point inside the
image/frame and then just checking the both image and frame boundary in
the loop. Not quite as efficient, but it really shouldn't matter too
much here.
Long transfers need to be split into multiple chunks because of
limitations by the spidev kernel driver. If this happens, we need to
make sure that the CS line remains high between the different chunks.
Add code to split the transfer into chunks and ask the driver to not
deassert CS after the transfer. Technically, this is only an
optimization as concurrent access to another device might still cause
deselection. However, this should mean that devices work without having
to change the spidev module parameter.
Use the feature in the hope that it will work. However, print a message
(not a warning), to help with debugging in case someone does run into
issues because of this.
Previously, we checked hidraw devices against drivers by using the
HIDIOCGRAWINFO ioctl. While this works, it's not ideal for doing unit
tests since umockdev would have to implement hidraw ioctls.
The new approach uses the HID_ID property on the parent hid device,
which contains the VID/PID pair.
The driver has an internal cancellable that simply forwards the external
cancellation in the cancel callback. This is not really needed, we can
instead just use the external cancellable directly by fetching it using
fpi_device_get_cancellable().
The (trivial) CRC code was copied from gstreamer. However, the license
stated here was LGPLv2 rather than LGPLv2.1+. Identical code can currently
be found upstream in gstreamer licensed under LGPLv2+. As such, update
the license, making it more compatible with the rest of libfprint.
Also add the "or any later version" to upekts.c. The library was already
LGPL2.1+ at the time and libthinkfinger authors approved a license
change.
This command is useful to immediately continue rather than waiting for
input. It is only useful for non-scanning device actions and can be
important when steps need to be explicitly skipped (e.g. to inject an
error in the second command without a way to wait in between).
We were attaching the sources to the default main context. Instead, we
should be attaching them to the current tasks main context (or, failing
that, the current thread local main context).
g_idle_add attaches to the default main context, but the rest of
libfprint is using the thread local main context. Switch to use the
internal fpi_device_add_timeout API for the workaround in order to
not rely on the default main context.
Unfortunately, the implementation was not thread safe and was not
sticking to the thread local main context.
In addition to this, it is not entirely clear to me how this API should
behave. The current approach is to simply cancel the transition with the
state machine halting in its current state. Instead, it could also make
sense for cancellation to cause the state machine to return a
G_IO_ERROR_CANCELLED.
As such, simply remove the feature for now. If anyone actually has a
good use-case then we can add it again.
libfprint uses the thread local context in almost all cases. Update
FpContext to also use it and make sure that any sources are removed when
the FpContext object is finalized. Otherwise we may run into
use-after-free issues.
In some situations one may want to guarantee that the last steps of an
SSM are run even when the SSM is completed early or failed.
This can easily be done by making fpi_ssm_mark_completed jump to the
next cleanup stage when called (this also includes mark_failed). Due to
the mechanism, it is still possible to explicitly jump cleanup states by
using fpi_ssm_jump_to_state, including a jump to the final state in
order to skip all cleanup states.
No need to provide a script that will break usage of `meson test --gdb`
when we can use a native and cleaner alternative.
We can then ignore LIBFPRINT_TEST_WRAPPER in basic tests, while it is
still needed by umockdev tests.
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.
Some USB transfer callbacks in this driver were freeing their transfer
buffer in their callbacks, which causes a double free since the transfer
itself frees them afterwards. Probably just got missed during the V2 api
changes.
These routines assume that any messages is composed of a write and/or
read part. While the API allows sending and receiving as part of one
messages/transfer, it does not permit full duplex operation where data is
both send and received at the same time.
This is primarily useful for SPI devices. These devices sometimes needs
a combination of an SPI and HID device, so discovery is a bit more
complicated.
We were crashing as trying to still call the identify vfunc, so check if
identification is supported and if not return a relative error.
Added test as well
Upstream systemd/udev is pulling our autosuspend hwdb, so if udev is new
enough, then there is no need to install the file. As such, add
auto-detection logic for the scenario.
This also changes the name of the option and the type to "feature".
The device will always use sequence number 0 for certain messages. We
use this knowledge to filter the messages and assume that it is one of
these special messages rather than a response to a command.
However, we could end up sending a command with a sequence counter of 0
which would result in the response being ignored. Fix this by ensuring
we correctly wrap from 255 to 1 instead of 0.
Fixes: #358
Some OEM will integrate fingerprint device with powerButton. It's
possible that a user may press the power button during fingerprint
enroll or identify. This would lead to unintended PC shutdown or
hibernation. We add pwr_btn_shield cmd and related process to shield
the power button function when the fingerprint functionality (enroll and
identify) is used and restore power button function afterwards.
We may want to be able to talk with the device while it's closed to
queue commands to be performed once it opens (could be even a script),
so to do this we need to close the device first, send those commands and
eventually process them.
We used a trick to send an invalid command before that was ignored by
release, but having the device available is just easier to handle.
So, when keep alive is enabled we don't stop the listener when closing
but only on actual device disposition.
The idea of the test was just checking what happens when we're opening a
device multiple times while a first request is still going.
However, it actually ends up also checking the previous commit change
because without it we'd stop the close iteration before the device is
actually closed and stop the open iteration before the device is
actually opened, leading to an infinite loop.
We're delaying any completed operation until we've completed an idle,
but the open/close state is changed and notified as soon as the device
completes the operation.
While this can be true, it means that we notify earlier than the finish
callback is actually called, while iterations are still needed to get
the actual state completed, and the current_task reset.
So if we'd open/close and iterate till fp_device_is_open() returns TRUE
we'd end up in a state in which the device is marked as ready, but it's
actually still busy since it's priv->current_task isn't unset yet.
The same if we'd try to do any action on notify::opened.
In case we do an early error return in verify and identify calls we
do not initialize the task data, but still in the finish functions we
still try to use it.
Avoid doing this, but just nullify the returned values.
When opening the device we can process commands that we left for that
after the previous close, to do that we only have to inject an invalid
command that will be processed (and ignored) while closing, so that at
next device opening we will be able to proceed with the previously
sent commands.
Add tests to finally check this case!
Each command should be separated by SLEEP to be considered as something
we want to perform during the current operation, otherwise will be used
by next operation consuming it.
In case we sent a sleep event to the device we may want to wait it to
emit the finger needed state before the timeout is completed.
So add a function to manage this for all the scan cases
The irq handler may already be stopped if stop_irq_handler is called. In
that case, we should immediately call the handler rather than just never
calling it.
This fixes deactivation when the device is unexpectedly unplugged.
Closes: #355
While meson suggests to always use 'library' this leads to some unwanted
behaviors when it comes to generate pkg-config files for it, as they
will include `Libs.Private` / `Required.private` fields that should not
be really part of a shared library as libfprint is meant to be used.
There are two variants one with storage and identify support and the
other without storage.
It implements the following commands:
* INSERT id
* REMOVE id
* SCAN id
* ERROR error-code
* LIST (returns saved print)
The INSERT/REMOVE/LIST commands are only available in the storage
driver. The SCAN command emulates presenting a finger.
These commands can be send ahead of time, and will be queued and
processed when appropriate. i.e. for INSERT/REMOVE that is immediately
when possible, for SCAN/ERROR processing is delayed.
The LIST command is always processed immediately.
Note that only a single command can be send per socket connection and
the command must be send in a single message. The socket will be closed
after the command has been processed.
Co-authored-by: Bastien Nocera <hadess@hadess.net>
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Instead of repeating the same code in both the virtual-image and the
virtual-device drivers, implement a class to handle the socket listening
an data reading.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
This solves various problems:
1. It stays the same also if some drivers have been disabled
2. It uses a stable path for being imported by systemd
3. It is still checked for its validity by tests
4. It can be auto-generated using a simple command
When building in big endian architectures some device tests will fail,
as per this we're pretty sure that most of the drivers are not ready
to work in big-endian architectures.
Since we're aware of this, better to just stop supporting those drivers
instead of having each distribution to handle the problem.
So, add a list of supported drivers that is filled depending the
architecture type we're building on. Keep continue building those
drivers since we want to at least test-build them, but do not expose
them as libfprint drivers, so if a device in the system uses any of them
will be ignored.
At the same time, we keep track of the problem, so that we can fix the
drivers.
Related to #236
The change to print a warning (for testing purposes) from commit
944e0d0383 (udev-rules: Print warning if an ID is supported) was
incorrect because it prevented duplicated to be suppressed if a device
is listed by two independent drivers.
Add a new test that checks that the unsupported list is not out of date.
As the wiki can be edited at any time, add this as a further optional
check into the CI pipeline.
As we are shipping a hwdb file now, we cannot have a collision with the
old libfprint version. Also, we are going to pull these rules into
systemd and they will not be installed via libfprint in the future. As
such, collisions will not happen again and it makes more sense like this
for systemd.
We want systemd to pull our hwdb. In order to ease this, always build
the hwdb file, even if it is disabled.
Once systemd has merged the rules, downstream should turn off the rules
in libfprint. The default in libfprint will also be changed to not build
the hwdb (udev_rules option) eventually.
We only use the rules/hwdb to enable auto-suspend. So, instead of
shipping our own rules, we can just use the existing autosuspend rules
and ship a hwdb that sets the appropriate flag.
Closes: #336
there is no specific API for report finger status,
finger needed status is set when captrue sample cmd send, once cmd receive correct,
finger is pressing on sensor.
Found by coverity. While quite bad in theory, proper safeguards are in
place, so it will only result in a g_return_val_if_fail to be hit rather
than causing more severe side effects.
We used to return early in the case where the print matched in order to
report the result more quickly. However, with the early reporting
mechanism and the fprintd side implementation of it, this is not
necessary anymore.
As such, only stop the "verify" and "identify" operations when the
finger is removed (or the operation is cancelled, which is actually what
will happen currently).
It is easier (and more correct) to create a new print from the reported
data and match that against the prints in the gallery.
We continue to return NULL during verify as we cannot provide any
additional information in that case.
NBIS just does weird things and while the array-parameter warning is
easy to fix, the other is not trivial. So disable these warnings so that
we can still build using newer GCC versions.
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.
This function was always documented to return a sunk reference, but it
did not do so. This change is technically backward incompatible.
However, it only has an effect if anything is doing a g_object_ref_sink.
Which may happen inside libfprint itself. With the change, most API
users (including fprintd) are fixed to do refcounting correctly. Any API
user which worked around this will have a memory leak now.
That is not ideal, but it is not really that bad overall. And returning
a floating reference for FpPrint creation was a bad idea in the first
place. And it really only makes sense for fp_print_new as the only
(public) use case is to create the template for enrollment.
When serializing an image print in big endian machine we ended up
swapping the arrays contents two times, first when adding the values and
eventually when calling g_variant_byteswap which already handles this
properly.
With this, we get the test passing into s390x.
Fixes: #236
Identify function is supposed to propagate a boolean value, but we make
it return an integer instead on idle, this can be normally the same in
most of architectures, but not in BE ones.
So, make it return the proper type.
Fixes test failures in s390x.
Related to #236
This tests all relevant scenarios of device removal, i.e.:
* device is not open
* device is currently closing
* device is open and idle
* device is currently opening
* device is open and active
The test ensures that in all scenarios the following holds true:
* device "removed" signal is only emitted after the action completes
* context "device-removed" signal is only emitted after the device has
been closed
Note that the "opening" case is special. Here we confirm that a success
from "open" will not be overriden by a FP_DEVICE_ERROR_REMOVED error, in
order to correctly signal that the internal device state is open and it
needs to be closed.
In general, we rely on the underlying transport layer to throw errors
which will abort the current operation. This does not work for the
virtual image device though, but we need it there for testing purposes.
Add a notify::removed handler that makes things work as expected. Let it
throw a protocol error which should not be visible to the outside.
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.
This enhances the device removal to create a well defined behaviour.
Primarily, it means that:
* "device-removed" will only be called for closed devices
* "removed" will be called only when no operation is active
Note that all actions will fail with FP_DEVICE_ERROR_REMOVED, *except*
for open which will only return this error if it failed.
Resolves: #330
When a new connection came in we would close the old connection. This in
turn would trigger a receive error causing the *new* connection to be
closed from the error handler.
Fix this by simply cancelling any pending transfers when a new
connection comes in. Also change the error handling code to catch issues
like partial writes correctly.
This fixes an issue for the fprintd test where some tests were flaky.
Some devices have storage but that's is limited enough not to be able
to store all the metadata, but just a fingerprint id.
In such case we also need to use the local storage to be able to verify.
Fprintd does this already, but we don't do it in the libfprint examples.
So, in in case we enroll, always save the print information to the disk,
while in case we verify we try to load the print from disk and we use
that in case its private data matches the one provided by the device.
While the image device has its own finger status tracking, we use a simpler
version as public data information, so let's just report the finger-on/off
and when a finger is expected to the parent class.
Verify that this happens as expected using the virtual-image class
It is not very useful to just delete the data again after a failure, as
it might be useful for debugging. Just store it into an "errors"
subdirectory of the PWD in the hope that this is a sane location.
Note that it'll error out if the directory already exists, but that
should be acceptable in all cases. i.e. it won't exist in the CI and
developers can just wipe the directory.
When porting the driver to the new libfprint 1.90.0 a mistake was made
where the device was not passed through user_data anymore but it was
still read from there. Stop using user_data in the callback to fix this.
See: #320
The elan driver always "deactivates" the device after a cpature run. We
can simplify the while internal state into a single "active" state and
rely on the image device driving this state machine correctly.
i.e.:
* We start a callibrate/capture/deactivate when we go into the
AWAIT_FINGER_ON state
* We only store the fact that we are active and want to deactivate
* We rely on the image device never going into the AWAIT_FINGER_ON
state without first waiting for the finger to be off (which implies
deactivation).
This adds a number of new internal states to better capture what is
going on. Also added are checks that all transitions we make are in the
set of expected and valid transitions.
Only three drivers use the state_change notification. These drivers are
updated accordingly.
The boolean is just used to emit a warning for unexpected state
transitions. It is sufficient to pass it to the deactivate function
directly for that purpose.
We might redo image transfers, but we only ever had one reference that
was implicitly removed after the transfer completed. Add a new reference
each time it is submitted and only free the last reference in the stop
handler.
For some reason we re-submitted the interrupt transfer with a timeout of
1s while the original submission was without a timeout. This looks like
typo, remove the timeout.
Annotate the USB transfer creation functions with the correct buffer
access attribute. Note that we only annotate them as read_only as the
functions may be used for sending and receiving.
Hopefully this will catch buffer overflows in drivers in the future.
Doing this avoids race conditions in testing code where the code might
try to submit errors/images before the device has been activated. This
would then (sometimes) trigger assertions in the image driver code.
The earlier image device code tried to hide deactivation from the
surrounding library. However, this does not make any sense anymore with
the early reporting feature present.
This changes the operation to complete only once the device is
deactivated. Also changed that in most cases (except for cancellation)
we wait for the finger to be removed before deactivating the device.
The driver seems to have relied on the device to be fully
deactivated and activated again for each capture. This is not the case
during enroll, and as such in can cause issues.
Try fixing this by splitting out the last few commands send to the
device and assuming that this starts the capture.
Fixes: #306
We have plenty of code paths where a transfer may be cancelled before it
is submitted. Unfortunately, libgusb up to and including version 0.3.6
are not handling that case correctly (due to libusb ignoring
cancellation on transfers that are not yet submitted).
Work around this, but do so in a somewhat lazy fashion that is not
entirely race free.
Closes: #306
Delay the open/close callbacks by 100ms so that we have a window of
opportunity for race conditions. This is needed to test certain
conditiosn in fprintd.
Adding a trailing \n to g_message, g_debug, g_warning and g_error is not
neccessary, as a newline will be added automatically by the logging
infrastructure.
The cancellable needs to be free'ed at deactivation. Also free it if we
run into a fatal error, which then in turn indicates that the device is
deactivated already.
The change_state function is called synchronously from the
image_captured callback. This means that deactivation of the device
happens during the img_cb function, causing the USB transfer to be
re-registered even though the device is already deactivating.
There are various ways to fix this, but it makes sense to directly bind
the cancellation to the deactivation. So create a cancellable that we
cancel at deactivation time, and make sure we always deactivate by going
through cancellation.
closes: #306
Image devices are simply deactivated suddenly. As such, the cancellation
logic of FpDevice is not really useful there, but the documentation was
apparently accidentally copied unmodified.
This is unlikely to happen in a real world scenario and currently breaks
running the CI test (not the umockdev based ones) while building the
flatpak. Lower the severity to avoid aborting because there is a
warning.
Image devices may return a FP_DEVICE_ERROR_NOT_SUPPORTED error once capture
is already started, in such case handle the error going in non imaging mode
This is based on the patch and observation from Bastien that some
URU4000B devices do not use encryption by default (it is a configuration
stored within the firmware). As such, it makes sense to always detect
whether encryption is in use by inspecting the image.
The encryption option would disable flipping of the image for the
URU400B device. Retain this behaviour for backward compatibility.
The code would just read 4096 bytes from the packet, without checking
the size and neither setting short_is_error. It is not clear whether
packets from the device are always 4096 bytes or not. But the code
assume we always get a full line, so enforce that and use the actual
packet size otherwise.
This was not used. The old driver used this if creating a USB transfer
failed, however, we delay any such failures (which cannot really happen)
into the callback today, where the error is handled differently.
The GPtrArray needs to be created at some point. Also, reference
counting was wrong as submitting the transfer sinks the ref, but we rely
on it surviving.
Note that we really should change this to only have one in-flight
transfer and starting a new one after it finishes.
Co-authored-by: Vasily Khoruzhick <anarsoul@gmail.com>
When sending static data, it would not be copied. The function that
sends it assumed that it should be free'ed though.
Fix this by simply always making a copy.
The driver would warn about the fact that a state change is queued, but
still queue it a second time. This would result in deactivation to run
twice.
See: #216
The image driver may still be deactivating when a new activation request
comes in. This is because of a hack to do early reporting, which is
technically not needed anymore.
Fix the immediate issue by properly reporting the retry case. The proper
fix is to only finish the previous operation after the device has been
deactivated.
One can set it in the project, but that doesn't get copied to forks. And
that means the coverage information isn't printed in MRs sometimes.
Just add it into .gitlab-ci.yml so that it always works.
The driver might forget to set the type of the print. Catch that error a
bit earlier rather than failing when the API user tries to load it from
disk again.
The type of the print (RAW or NBIS) needs to be filled in by the driver.
For most drivers the image devices does this (NBIS), but the
corresponding call was missing in the upekts driver, rendering the
enrolled print unusable.
__handle_incoming_msg would copy the payload of the message into a newly
created buffer just to destroy it again immediately after calling the
callback. Just reference the correct address inside the original package
instead.
Also, in one case the extra buffer was leaked afterwards.
The driver would correctly calculate the amount of extra space needed to
receive the whole packet. It would also request the correct number of
bytes for this transfer.
However, the reallocated buffer to hold this data was directly derived
from the expected payload size and did not include the overhead.
Make the code more explicit and get rid of the confusing
MAX_DATA_IN_READ_BUF define that hides details on buffer allocation
calculation from the code.
The device is already beeing de-initialised from the verify/enroll
commands. Trying it again will result in a timeout error as it is not
responding properly at that point.
And activate perimeter points removal if this flag is set
This flag should be set for aes1610, aesx660, aes2501, aes2550
and upektc_img since these sensors may produce incomplete image.
Fixes: #142
This step helps to drop false minutiae for short sensors and
it was accidentally dropped during NBIS update. Re-add this step
and add a patch to update script to ensure that it's not dropped
during next update.
Fixes: 9fb789dc78 ("nbis: Update to NBIS 5.0.0")
Not having the diff is a bit painfull when the local version of
uncrustify differs from the one on the CI runner. So uncrustify in-place
and output the diff.
If a transfer errors out then actual_length is negative. The only error
that is not caught is a timeout error, which should also result in the
SSM to move to the next state.
We build the HTML documentation. For feature branches, it is convenient
to be able to view the documentation easily. Expose them as artifacts
and add a link to the browser underneath the pipeline in the MR.
Unfortunately, it does not seem to be possible to link directly to the
HTML.
For some reason static checkers report that the auto-free is not run if
the goto exists the loop. It seems to me like that should work fine, but
we can simply make the analysers happy by moving it.
We need more than 1 line for assembling, but in general, we should
have a reasonable amount of lines. So use the width in the hope we'll
get an image that is about square at least.
Closes: #135
When no driver is found for an USB device a debug message is
printed. However, it has PID and VID in wrong order - usually it
is Vendor ID which goes first. This is how 'lsusb' prints it.
Matching the order helps debugging.
Signed-off-by: Michal Privoznik <michal@privoznik.com>
In the fpi_print_fill_from_user_id() GDate is defined using
g_autoptr(). However, this requires new enough GLib. For older
versions there's a definition provided locally in fpi-compact.h.
Include the file to fix build with older version of GLib.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
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
The minutiae detection might fail and we must not copy any data at that
point. So check g_task_had_error to ensure that we only do so when the
task was successful.
Fixes: #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
libfprint/fp-print.c: In function ‘fp_print_equal’:
libfprint/fp-print.c:596:21: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’} [-Wsign-compare]
596 | for (i = 0; i < self->prints->len; i++)
| ^
libfprint/fp-print.c: In function ‘fp_print_serialize’:
libfprint/fp-print.c:667:21: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’} [-Wsign-compare]
667 | for (i = 0; i < print->prints->len; i++)
| ^
libfprint/fp-print.c: In function ‘fp_print_deserialize’:
libfprint/fp-print.c:823:21: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘gsize’ {aka ‘long unsigned int’} [-Wsign-compare]
823 | for (i = 0; i < g_variant_n_children (prints); i++)
| ^
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
The public API uses gio and gobject header, ensure that these are in the
list of Required pkg-config modules, otherwise they are added to
Required.private which is not OK.
It appears the order of linking is relevant in this case, change it to
fix some linking issues.
It may be that there are better solutions to this problem.
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
Without this we get warnings like the following:
cc1: warning: .../_build/libfprint/nbis/libfprint-include: No such file or directory [-Wmissing-include-dirs]
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
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
The callback function would continue processing even after having failed
the SSM already. This causes further invalid operations on the SSM.
This error was found using a coverity scan.
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
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.
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 were not testing the image device error reporting functions yet
inside libfprint (fprintd already had such tests). Add tests to make
sure we catch errors earlier.
It is a good idea to report match results early, to e.g. log in a user
immediately even if more device interaction is needed. Add new _full
variants for the verify/identify functions, with a corresponding
callback. Also move driver result reporting into new
fpi_device_{identify,verify}_report functions and remove the reporting
from the fpi_device_{identify,verify}_complete calls.
Basic updates to code is done in places. Only the upekts driver is
actually modified from a behaviour point of view. The image driver code
should be restructured quite a bit to split the reporting and only
report completion after device deactivation. This should simplifiy the
code quite a bit again.
Some things were odd with regard to the ownership of passed objects. Try
to make things sane overall, in particular with the possible floating
FpPrint reference.
The progress report user data free func was not assigned and therefore
never called. Add the missing assign, potentially fixing memory leaks
(mostly relevant for bindings).
Just hiding tests that cannot be run does not seem like the best idea.
So add dummy tests that are skipped, to denote that we could test more
than we actually do (even if it is just for drivers that are not
enabled).
Unfortunately, the timeout handling cannot be simulated properly. This
also adds a workaround in the driver to not consider it a protocol error
if this happens.
Continuing an enroll was broken in case of a retry error. Explicitly add
code to wait for the finger to go OFF after a retry error, and ensure
that the enroll will continue once that has happened.
We cannot copy information from the class in the _init routine, instead,
this needs to be done in _constructed. Move the relevant code into a new
_constructed function to fix importing the bz3_threshold override from
drivers.
Fixes: #206
The offset stored for a frame was not always relative to the previous
frame. This was the case for reverse movement, but for forwrad movement
the offset was the one to the next frame.
Make the offset handling consistent and alwasy store the offset to the
previous frame. Also update the frame assembling code to add the offset
before blitting the frame (i.e. making it relative to the previous frame
there too).
Note that fpi_assemble_lines already made the assumption that this was
the case as it forced the offset for the first frame to be zero. As
such, the code was inconsistent.
This could affect the AES drivers slightly as they use hardware reported
values which might not adhere to these assumptions.
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 prefixed them with fp- which is not as obvious as fpi-. Also,
explicitly mark them as private and to be skipped in the GObject
Introspection annotatinos.
Warning: FPrint: (Signal)fp-image-device-state-changed: argument object: Unresolved type: 'FpiImageDeviceState'
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.
The private library needs to indirectly include fp-enum.h. This
dependency was not listed anyway, resulting in a race condition during
the build process.
The elan driver converts frames into a different format. These frames
are only needed to assemable the image and should be free'ed afterwards.
Fixes: #213
The manage-prints command would close the device twice when the user
hits an invalid number or 'n' and no prints need to be deleted.
Simply remove the erroneous call to fix the issue.
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.
This fixes the the problem that the sensor becomes unresponsive after
pressing the wrong fingerprint. We fix the problem by making sure that
the non-match report is delayed until the finger is removed. With this
we cannot run into the situation that the next match request fails
immediately as the finger is still present.
Fixes: #208
The FPI_MATCH_ERROR constant was set to 0, however it is propagated to
the task completion using g_task_propagate_int. As g_task_propagate_int
will always return -1 on error, we either need to add an explicit -1
check or we just need to match the semantics.
Change the constant to -1, also rearange FP_MATCH_SUCCESS so that it
does not end up being 0.
This also changes the code to keep the connection open and adds
automatic mainloop iteration to ensure the driver processes the request.
This is important so we will not deadlock when we send multiple
requests.
Add commands to disable automatic finger reporting for images and to
send a specific finger report. This is useful to test more code paths
inside the image-device code.
Add fpi_ssm_new_full() that allows to pass a name to the state-machine
constructor, not to change all the drivers, provide a fpi_ssm_new() macro
that stringifies the nr_parameters value (usually an enum value) as the name
so that we can use it for better debugging.
The IRQ handler will re-register itself automatically. However, if this
happens after the callback is called, then the check whether the IRQ
handler is running fails.
Re-start the IRQ handler before calling the callback. This way the state
changes happening from the callback will see the correct IRQ handler
registration state.
See: #205
At the end of enroll, the image device would put the driver into the
AWAIT_FINGER_ON state and then deactivate the device afterwards. Doing
this adds additional complexity to drivers which would need to handle
both cancellation and normal deactivation from that state.
Only put the device into the AWAIT_FINGER_ON state when we know that
another enroll stage is needed. This avoids the critical state
transition simplifying the driver state machine.
Fixes: #203
Fixes: 689aff0232
During calibration, the internal state was stored as INACTIVE. This is
not true though, the device is actively running state machines.
Move the state update to the start of the operation, therefore ensuring
we don't deactivate without completing the SSM.
Note that this will prevent a crash, but the driver still does not
behave quite correctly when such a state change does happen. However,
this is just a safety measure as the state change should not happen in
the first place.
See: #203
These were probably added in previous iterations, but they are not uneeded
anymore as the GSource embeds already a callback function.
So make just this clearer in the dispatch function.
Now that nbis is a static library it should be possible to compile it
without any fprint-built dependency, although since it included fp_internal
there was a compile-time dependency on the fp-enums that can be generated at
later times.
So:
- Move nbis-helpers to nbis includes (and remove inclusion in fp_internal)
- Move the Minutiae definitions inside a standalone fpi-minutiae header
- Include fpi-minutiae.h in fp_internal.h
- Include nbis-hepers.h and fpi-minutiae.h in nbis' lfs.h
- Adapt missing definitions in libfprint
The nbis headers are full of redundant declarations, we can't fix them all
now, so in the mean time let's use an header using pragma to ignore such
errors.
Add the error to nbis private include folder that should be used only by
headers of libfprint-nbis.
As nbis is an external source bundle, it does not necessarily make sense
to enable/fix all warnings to the extend we do for our own library code.
As such, separate the build process into multiple stages.
We were passing around the common cflags and setting them for each library
or executable, but this is just a repetition given we can just use
add_project_arguments for this.
Properly follow function signature using a temporary gsize variable address
to make the function use the same pointer type and avoid troubles at
deferencing it, while use automatic-casting to switch to signed one if
transfer succeeded.
The code tried to only write the RGB bytes of FORMAT_RGB24, however, the
in-memory layout is different on big-endian which would result in the
wrong bytes being written.
Fix this by simply also writing the byte we do not care about.
2019-12-04 13:23:08 +01:00
302 changed files with 98659 additions and 5680 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
