If the tile in question was hanging over the left edge we would not be
copying the full available width. Fix this and change the test to catch
the error condition (by forcing a too small image and overlap both
ways).
Simplify the code by only selecting the starting point inside the
image/frame and then just checking the both image and frame boundary in
the loop. Not quite as efficient, but it really shouldn't matter too
much here.
Long transfers need to be split into multiple chunks because of
limitations by the spidev kernel driver. If this happens, we need to
make sure that the CS line remains high between the different chunks.
Add code to split the transfer into chunks and ask the driver to not
deassert CS after the transfer. Technically, this is only an
optimization as concurrent access to another device might still cause
deselection. However, this should mean that devices work without having
to change the spidev module parameter.
Use the feature in the hope that it will work. However, print a message
(not a warning), to help with debugging in case someone does run into
issues because of this.
Previously, we checked hidraw devices against drivers by using the
HIDIOCGRAWINFO ioctl. While this works, it's not ideal for doing unit
tests since umockdev would have to implement hidraw ioctls.
The new approach uses the HID_ID property on the parent hid device,
which contains the VID/PID pair.
The driver has an internal cancellable that simply forwards the external
cancellation in the cancel callback. This is not really needed, we can
instead just use the external cancellable directly by fetching it using
fpi_device_get_cancellable().
The (trivial) CRC code was copied from gstreamer. However, the license
stated here was LGPLv2 rather than LGPLv2.1+. Identical code can currently
be found upstream in gstreamer licensed under LGPLv2+. As such, update
the license, making it more compatible with the rest of libfprint.
Also add the "or any later version" to upekts.c. The library was already
LGPL2.1+ at the time and libthinkfinger authors approved a license
change.
This command is useful to immediately continue rather than waiting for
input. It is only useful for non-scanning device actions and can be
important when steps need to be explicitly skipped (e.g. to inject an
error in the second command without a way to wait in between).
We were attaching the sources to the default main context. Instead, we
should be attaching them to the current tasks main context (or, failing
that, the current thread local main context).
g_idle_add attaches to the default main context, but the rest of
libfprint is using the thread local main context. Switch to use the
internal fpi_device_add_timeout API for the workaround in order to
not rely on the default main context.
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.
libfprint uses the thread local context in almost all cases. Update
FpContext to also use it and make sure that any sources are removed when
the FpContext object is finalized. Otherwise we may run into
use-after-free issues.
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.
We can avoid having multiple device feature-check functions now and
just rely on a few.
Add uncrustify config to properly handle begin/end deprecation macros.
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.
We always assumed a device can verify, but nothing prevents from having
a device that only can identify or capture.
So, given that we've more fine grained checks, let's stop the task if
this is the case.
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.
These routines assume that any messages is composed of a write and/or
read part. While the API allows sending and receiving as part of one
messages/transfer, it does not permit full duplex operation where data is
both send and received at the same time.
This is primarily useful for SPI devices. These devices sometimes needs
a combination of an SPI and HID device, so discovery is a bit more
complicated.
We were crashing as trying to still call the identify vfunc, so check if
identification is supported and if not return a relative error.
Added test as well
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.
We're delaying any completed operation until we've completed an idle,
but the open/close state is changed and notified as soon as the device
completes the operation.
While this can be true, it means that we notify earlier than the finish
callback is actually called, while iterations are still needed to get
the actual state completed, and the current_task reset.
So if we'd open/close and iterate till fp_device_is_open() returns TRUE
we'd end up in a state in which the device is marked as ready, but it's
actually still busy since it's priv->current_task isn't unset yet.
The same if we'd try to do any action on notify::opened.
In case we do an early error return in verify and identify calls we
do not initialize the task data, but still in the finish functions we
still try to use it.
Avoid doing this, but just nullify the returned values.
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
While meson suggests to always use 'library' this leads to some unwanted
behaviors when it comes to generate pkg-config files for it, as they
will include `Libs.Private` / `Required.private` fields that should not
be really part of a shared library as libfprint is meant to be used.
There are two variants one with storage and identify support and the
other without storage.
It implements the following commands:
* INSERT id
* REMOVE id
* SCAN id
* ERROR error-code
* LIST (returns saved print)
The INSERT/REMOVE/LIST commands are only available in the storage
driver. The SCAN command emulates presenting a finger.
These commands can be send ahead of time, and will be queued and
processed when appropriate. i.e. for INSERT/REMOVE that is immediately
when possible, for SCAN/ERROR processing is delayed.
The LIST command is always processed immediately.
Note that only a single command can be send per socket connection and
the command must be send in a single message. The socket will be closed
after the command has been processed.
Co-authored-by: Bastien Nocera <hadess@hadess.net>
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
