Unfortunately, the implementation was not thread safe and was not
sticking to the thread local main context.
In addition to this, it is not entirely clear to me how this API should
behave. The current approach is to simply cancel the transition with the
state machine halting in its current state. Instead, it could also make
sense for cancellation to cause the state machine to return a
G_IO_ERROR_CANCELLED.
As such, simply remove the feature for now. If anyone actually has a
good use-case then we can add it again.
In some situations one may want to guarantee that the last steps of an
SSM are run even when the SSM is completed early or failed.
This can easily be done by making fpi_ssm_mark_completed jump to the
next cleanup stage when called (this also includes mark_failed). Due to
the mechanism, it is still possible to explicitly jump cleanup states by
using fpi_ssm_jump_to_state, including a jump to the final state in
order to skip all cleanup states.
It can be convenient for device users to check what it supports, without
having multiple functions to check each single feature.
So expose this and add tests.
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.
Some USB transfer callbacks in this driver were freeing their transfer
buffer in their callbacks, which causes a double free since the transfer
itself frees them afterwards. Probably just got missed during the V2 api
changes.
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
Some OEM will integrate fingerprint device with powerButton. It's
possible that a user may press the power button during fingerprint
enroll or identify. This would lead to unintended PC shutdown or
hibernation. We add pwr_btn_shield cmd and related process to shield
the power button function when the fingerprint functionality (enroll and
identify) is used and restore power button function afterwards.
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
The irq handler may already be stopped if stop_irq_handler is called. In
that case, we should immediately call the handler rather than just never
calling it.
This fixes deactivation when the device is unexpectedly unplugged.
Closes: #355
