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 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.
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.
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
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
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
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.
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
