Ge-org Brohammer
3a41fa7ccc
Deleting a print whose template is not in the sensor's storage makes the driver fail its task SSM, which is the path that handed an already-freed GError to fpi_device_delete_complete(). Reading the reported error is therefore what the test is for. No enrollment is involved: the test deserializes a stored realtek print whose template is deliberately not on the device, so the recording needs no finger presses and the capture stays at 90 packets. Without the previous commit the test dies rather than fails: umockdev-run ... died with <Signals.SIGSEGV: 11> 1/1 drivers+custom - libfprint:realtek-storage-errors FAIL The duplicate-enrollment path reaches the same bug through fp_enroll_ssm_done(), but capturing it needs two full enrollments and some 1.07M packets of polling traffic, so it is left out here.
umockdev Tests
umockdev tests use fingerprint devices mocked by umockdev
toolchain.
This document describes how to create test cases (for USB devices). Many of these tests are tests for image devices, where a single image is captured and stored.
Other kinds of umockdev tests can be created in a similar manner. For
match-on-chip devices you would instead create a test specific custom.py
script, capture it and store the capture to custom.pcapng.
'capture' and 'custom' Test Creation
For image devices, use the capture test to capture one reference image. For
non-image drivers, create a custom.py script in advance and select the
custom test instead.
-
Make sure that libfprint is built with support for the device driver that you want to create a test case for.
-
From the build directory, run tests/create-driver-test.py as root. Note that if you're capturing data for a driver which already has a test case but the hardware is slightly different, you might want to pass a variant name as a command-line options, for example:
$ sudo tests/create-driver-test.py [--test capture|custom] driver [variant]
By default, the tool runs capture.py and, when present, the test directory's
custom.py. Use --test capture or --test custom to record only that test.
-
If the capture is not successful, run the tool again to start another capture.
-
Add driver test name to
drivers_testsin themeson.build, as instructed, and change the ownership of the just-created test directory in the source. -
Check whether
meson testpasses with this new test.
Note. To avoid submitting a real fingerprint when creating a 'capture' test, the side of finger, arm, or anything else producing an image with the device can be used.
Possible Issues
Other changes may be needed to get everything working. For example the
elan driver relies on a timeout that is not reported correctly. In
this case the driver works around it by interpreting the protocol
error differently in the virtual environment (by means of
FP_DEVICE_EMULATION environment variable).