Identify function is supposed to propagate a boolean value, but we make
it return an integer instead on idle, this can be normally the same in
most of architectures, but not in BE ones.
So, make it return the proper type.
Fixes test failures in s390x.
Related to #236
Tag 1.90.5
Git-EVTag-v0-SHA512: 05650e2a6cf2290542936271b140e79015f56e35fbffc4677e37bf30963b2a38b49eb699db80cee6677ff348ea9e8548514a9f1e06a767269e44d7fac3334c45
When serializing an image print in big endian machine we ended up
swapping the arrays contents two times, first when adding the values and
eventually when calling g_variant_byteswap which already handles this
properly.
With this, we get the test passing into s390x.
Fixes: #236
Identify function is supposed to propagate a boolean value, but we make
it return an integer instead on idle, this can be normally the same in
most of architectures, but not in BE ones.
So, make it return the proper type.
Fixes test failures in s390x.
Related to #236
This tests all relevant scenarios of device removal, i.e.:
* device is not open
* device is currently closing
* device is open and idle
* device is currently opening
* device is open and active
The test ensures that in all scenarios the following holds true:
* device "removed" signal is only emitted after the action completes
* context "device-removed" signal is only emitted after the device has
been closed
Note that the "opening" case is special. Here we confirm that a success
from "open" will not be overriden by a FP_DEVICE_ERROR_REMOVED error, in
order to correctly signal that the internal device state is open and it
needs to be closed.
In general, we rely on the underlying transport layer to throw errors
which will abort the current operation. This does not work for the
virtual image device though, but we need it there for testing purposes.
Add a notify::removed handler that makes things work as expected. Let it
throw a protocol error which should not be visible to the outside.
We require the close call, but as the underlying transport layer is
gone, it will generally just return an error.
In principle, it makes sense to think of close as a function that always
succeeds (i.e. it makes no sense to try again). Should the device be in
a bad state, then a subsequent open() will simply fail.
This enhances the device removal to create a well defined behaviour.
Primarily, it means that:
* "device-removed" will only be called for closed devices
* "removed" will be called only when no operation is active
Note that all actions will fail with FP_DEVICE_ERROR_REMOVED, *except*
for open which will only return this error if it failed.
Resolves: #330
When a new connection came in we would close the old connection. This in
turn would trigger a receive error causing the *new* connection to be
closed from the error handler.
Fix this by simply cancelling any pending transfers when a new
connection comes in. Also change the error handling code to catch issues
like partial writes correctly.
This fixes an issue for the fprintd test where some tests were flaky.
Some devices have storage but that's is limited enough not to be able
to store all the metadata, but just a fingerprint id.
In such case we also need to use the local storage to be able to verify.
Fprintd does this already, but we don't do it in the libfprint examples.
So, in in case we enroll, always save the print information to the disk,
while in case we verify we try to load the print from disk and we use
that in case its private data matches the one provided by the device.
While the image device has its own finger status tracking, we use a simpler
version as public data information, so let's just report the finger-on/off
and when a finger is expected to the parent class.
Verify that this happens as expected using the virtual-image class
It is not very useful to just delete the data again after a failure, as
it might be useful for debugging. Just store it into an "errors"
subdirectory of the PWD in the hope that this is a sane location.
Note that it'll error out if the directory already exists, but that
should be acceptable in all cases. i.e. it won't exist in the CI and
developers can just wipe the directory.
Marco Trevisan (Treviño)