It appears the kernel automatically "fixes" this mistake and it works.
the transfer in question is an interrupt transfer and should be submitted
as such. Do that in order to make things more correct and so that the
test can run.
Expose new versioned symbols that work with previous API so that we can
keep compatibility with old drivers without having to recompile them.
We disable the GCancellable API in delayed SSM actions since that was
something that wasn't really needed and prone to errors, instead of
just re-implementing it as it was in the TOD case.
Recompile tod drivers using libfprint-tod-test-drivers project [1] so
that we don't have to reorder the private driver structure, plus use a
versioned driver ID and parse it to check whether a feature is supported
for such TOD test driver.
https://gitlab.freedesktop.org/3v1n0/libfprint-tod-test-drivers
Tag 1.94.0
Git-EVTag-v0-SHA512: 7cf9d7defb02433140f575589099569a5848ab34e8ecb0a4a90bb3c9eb1c228a16438afe1b23c381b59c1506f189a845752fead3dbd3c1c11f686cf47302cb1b
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 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.
The assumption here is that in most cases, we will just cancel any
ongoing operation. However, if the device choses to implement
suspend/resume handling and it returns success, then operations will not
be cancelled.
Note that suspend/resume requests cannot be cancelled.
Closes: #256
Benjamin Berg