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.
