Adds an image driver for the Samsung USB fingerprint sensor
(04e8:7305) shipped in the Samsung Notebook 7 Spin
(NP730QAA-K02US). The protocol was reverse-engineered from
USB captures of the Windows vendor driver.
The sensor is a 56x192 8-bit grayscale area sensor. Capture
requires a 4-trigger sequence (3 pre-capture strip reads plus
one full-frame read) and a vendor control-transfer bracket
(heartbeat / response-length prime / wait-ready doorbell on
EP0) around every bulk transfer.
The sensor is physically a press sensor but is declared as
FP_SCAN_TYPE_SWIPE and assembled from multiple frames via
fpi_assemble_frames(), because NBIS's minutia extractor needs
more ridge area than a single 56x192 frame provides. An
inline comment near ASSEMBLE_STRIDE explains the rationale
and references drivers/elan.c for precedent.
A umockdev-based capture test is included. Protocol
documentation and development history:
https://github.com/jwhall/samsung7305
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
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
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`.
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.
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>
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.
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
