We re-aquire the critical section at the start of the callback, however,
it needs to be dropped again (or not taken) if the interrupt transfer is
resubmitted.
The error may not be NULL, as such we need a second variable and then
we'll only forward any error from g_usb_device_release_interface if
there was none before.
We only allow suspending while we are in the interrupt transfer stage.
To suspend, we cancel the interrupt transfer and at resume time we
restart it.
This has been tested to work correctly on an X1 Carbon 8th Gen with
suspend mode set to "Windows 10" (i.e. S0ix [s2idle] and not S3 [suspend
to RAM]). With S3 suspend, the USB root hub appears to be turned off or
reset and the device will be unresponsive afterwards (if it returns). To
avoid issues, libfprint disables the "persist" mode in the kernel and
we'll see a new device instead after resume.
This temperature model has three states:
* COLD
* WARM
* HOT
Device drivers can define the time it requires for the device to get HOT
and COLD. The underlying model assumes an exponential warming and
cooling process and enforces a cool-off time after the device has
reached the HOT state. This cool down period is however shorter than the
specified time in the driver.
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.
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.
The device will always use sequence number 0 for certain messages. We
use this knowledge to filter the messages and assume that it is one of
these special messages rather than a response to a command.
However, we could end up sending a command with a sequence counter of 0
which would result in the response being ignored. Fix this by ensuring
we correctly wrap from 255 to 1 instead of 0.
Fixes: #358
We used to return early in the case where the print matched in order to
report the result more quickly. However, with the early reporting
mechanism and the fprintd side implementation of it, this is not
necessary anymore.
As such, only stop the "verify" and "identify" operations when the
finger is removed (or the operation is cancelled, which is actually what
will happen currently).
It is easier (and more correct) to create a new print from the reported
data and match that against the prints in the gallery.
We continue to return NULL during verify as we cannot provide any
additional information in that case.
For some reason we re-submitted the interrupt transfer with a timeout of
1s while the original submission was without a timeout. This looks like
typo, remove the timeout.
When quickly scanning a finger with the synaptic driver, it may wait forever
for finger removal even if this has already happened.
In fact we don't take care of the finger status when reporting the
verification.
To avoid this, add a function that delays the completion of the verification
until the finger removal if the finger is on sensor, otherwise it just
performs it.
Fixes#228
Nkaspers