Don't make headers inclusions dependent on each others, given that FpiSsm
depends on FpiUsbTransfer and vice-versa, so fix the dependency cycle by
using forwarded declarations.
The private library needs to indirectly include fp-enum.h. This
dependency was not listed anyway, resulting in a race condition during
the build process.
The elan driver converts frames into a different format. These frames
are only needed to assemable the image and should be free'ed afterwards.
Fixes: #213
While timeout was already cleared for parent, we didn't properly delete the
cancellable.
Although we'd warn anyways when starting the SSM, is still better to clear
any delayed action also for the sub-SSM
In order to be able to test the private device code (used by drivers) we
need to have that split a part in a different .c file so that we can compile
it alone and link with it both the shared library and the test executables.
Redefine fp_image_device_get_instance_private for private usage, not to move
the private struct as part of FpDevice.
In order to be able to test the private device code (used by drivers) we
need to have that split a part in a different .c file so that we can compile
it alone and link with it both the shared library and the test executables.
Redefine fp_device_get_instance_private for private usage, not to move
the private struct as part of FpDevice.
A Fp-device use an union to track the handle to the lower-level device, and
the value depends on the object type.
So in case of using a virtual device, the priv->usb_device location matches
the priv->virtual_env string location, and thus we'd end up unreffing a
string location as it was a GObject, while we'd leak the string.
To avoid such errors, instead of just checking the device type when we
finalize the device, let's just use different pointers to avoid other
possible clashes.
This fixes the the problem that the sensor becomes unresponsive after
pressing the wrong fingerprint. We fix the problem by making sure that
the non-match report is delayed until the finger is removed. With this
we cannot run into the situation that the next match request fails
immediately as the finger is still present.
Fixes: #208
The FPI_MATCH_ERROR constant was set to 0, however it is propagated to
the task completion using g_task_propagate_int. As g_task_propagate_int
will always return -1 on error, we either need to add an explicit -1
check or we just need to match the semantics.
Change the constant to -1, also rearange FP_MATCH_SUCCESS so that it
does not end up being 0.
Add commands to disable automatic finger reporting for images and to
send a specific finger report. This is useful to test more code paths
inside the image-device code.
Add fpi_ssm_new_full() that allows to pass a name to the state-machine
constructor, not to change all the drivers, provide a fpi_ssm_new() macro
that stringifies the nr_parameters value (usually an enum value) as the name
so that we can use it for better debugging.
The IRQ handler will re-register itself automatically. However, if this
happens after the callback is called, then the check whether the IRQ
handler is running fails.
Re-start the IRQ handler before calling the callback. This way the state
changes happening from the callback will see the correct IRQ handler
registration state.
See: #205
At the end of enroll, the image device would put the driver into the
AWAIT_FINGER_ON state and then deactivate the device afterwards. Doing
this adds additional complexity to drivers which would need to handle
both cancellation and normal deactivation from that state.
Only put the device into the AWAIT_FINGER_ON state when we know that
another enroll stage is needed. This avoids the critical state
transition simplifying the driver state machine.
Fixes: #203
Fixes: 689aff0232
During calibration, the internal state was stored as INACTIVE. This is
not true though, the device is actively running state machines.
Move the state update to the start of the operation, therefore ensuring
we don't deactivate without completing the SSM.
Note that this will prevent a crash, but the driver still does not
behave quite correctly when such a state change does happen. However,
this is just a safety measure as the state change should not happen in
the first place.
See: #203
These were probably added in previous iterations, but they are not uneeded
anymore as the GSource embeds already a callback function.
So make just this clearer in the dispatch function.
