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>
Instead of repeating the same code in both the virtual-image and the
virtual-device drivers, implement a class to handle the socket listening
an data reading.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
This solves various problems:
1. It stays the same also if some drivers have been disabled
2. It uses a stable path for being imported by systemd
3. It is still checked for its validity by tests
4. It can be auto-generated using a simple command
The change to print a warning (for testing purposes) from commit
944e0d0383 (udev-rules: Print warning if an ID is supported) was
incorrect because it prevented duplicated to be suppressed if a device
is listed by two independent drivers.
As we are shipping a hwdb file now, we cannot have a collision with the
old libfprint version. Also, we are going to pull these rules into
systemd and they will not be installed via libfprint in the future. As
such, collisions will not happen again and it makes more sense like this
for systemd.
We want systemd to pull our hwdb. In order to ease this, always build
the hwdb file, even if it is disabled.
Once systemd has merged the rules, downstream should turn off the rules
in libfprint. The default in libfprint will also be changed to not build
the hwdb (udev_rules option) eventually.
We only use the rules/hwdb to enable auto-suspend. So, instead of
shipping our own rules, we can just use the existing autosuspend rules
and ship a hwdb that sets the appropriate flag.
Closes: #336
there is no specific API for report finger status,
finger needed status is set when captrue sample cmd send, once cmd receive correct,
finger is pressing on sensor.
Found by coverity. While quite bad in theory, proper safeguards are in
place, so it will only result in a g_return_val_if_fail to be hit rather
than causing more severe side effects.
We used to return early in the case where the print matched in order to
report the result more quickly. However, with the early reporting
mechanism and the fprintd side implementation of it, this is not
necessary anymore.
As such, only stop the "verify" and "identify" operations when the
finger is removed (or the operation is cancelled, which is actually what
will happen currently).
It is easier (and more correct) to create a new print from the reported
data and match that against the prints in the gallery.
We continue to return NULL during verify as we cannot provide any
additional information in that case.
NBIS just does weird things and while the array-parameter warning is
easy to fix, the other is not trivial. So disable these warnings so that
we can still build using newer GCC versions.
This function was always documented to return a sunk reference, but it
did not do so. This change is technically backward incompatible.
However, it only has an effect if anything is doing a g_object_ref_sink.
Which may happen inside libfprint itself. With the change, most API
users (including fprintd) are fixed to do refcounting correctly. Any API
user which worked around this will have a memory leak now.
That is not ideal, but it is not really that bad overall. And returning
a floating reference for FpPrint creation was a bad idea in the first
place. And it really only makes sense for fp_print_new as the only
(public) use case is to create the template for enrollment.
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
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