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.
The timeout is designed to continue commands automatically that are
common (e.g. opening the device). This doesn't really make sense for
scan commands, and removing the timeout enables test setups where user
interaction with the device may happen at arbitrary times.
One exception is device removal/unplug, in which case the timeout will
be added anyway.
This command is useful to immediately continue rather than waiting for
input. It is only useful for non-scanning device actions and can be
important when steps need to be explicitly skipped (e.g. to inject an
error in the second command without a way to wait in between).
Allows drivers to define more fine grained features for devices, not
strictly depending on assumptions we can make depending on the
implemented vfuncs.
We keep this per class but could be in theory moved to each instance.
In any case, added an utility function to initialize it in the way we
can ensure that we've a consistent way for setting them across all the
devices.
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.
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
There are two variants one with storage and identify support and the
other without storage.
It implements the following commands:
* INSERT id
* REMOVE id
* SCAN id
* ERROR error-code
* LIST (returns saved print)
The INSERT/REMOVE/LIST commands are only available in the storage
driver. The SCAN command emulates presenting a finger.
These commands can be send ahead of time, and will be queued and
processed when appropriate. i.e. for INSERT/REMOVE that is immediately
when possible, for SCAN/ERROR processing is delayed.
The LIST command is always processed immediately.
Note that only a single command can be send per socket connection and
the command must be send in a single message. The socket will be closed
after the command has been processed.
Co-authored-by: Bastien Nocera <hadess@hadess.net>
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
