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