The new libfprint version has support for devices that store data on the
sensor. In that case, the on-sensor storage might fill up when the user
tries to enroll a new print.
The strategy introduced here to handle this is to try and delete prints
from the device that we do not know about (assuming, it is e.g. from an
old installation and unusable).
It can also happen that we are not able to garbage collect old prints.
If that happens, a new error code "enroll-data-full" will be returned
signalling the situation to the enrolling application.
For sensors with internal storage we may want to garbage collect prints.
Adding this API means we can list all local prints, allowing us to find
out whether there are prints on the device's storage with no
corresponding print on the host.
fprintd's API docs say that "retry" errors for verification
"the verification is still ongoing" and that "[the] user should retry
scanning their finger.
Unfortunately, retry errors are fatal in libfprint. Make fprintd restart
operations when "retry" is the error for either identification or
verification purposes.
We need to also make sure that a "*Stop" D-Bus call will return as
normal if called while we're stopping a verification or identification
in order to restart it.
Closes: #22
--localstatedir (and --prefix) will now be ignored in favour of this
hardcoded path. This is in preparation for a change to use systemd's
StateDirectory feature.
Otherwise you could get into a state where the daemon could not start
because the directory listed as a ReadWritePaths in the .service file is
missing.
Spotted by Will Thompson.
See: !5
Fix a possible crash when an fprintd client disappears. If the client
requested for the device to be released, then, without waiting for the
reply of that release, disappeared from the bus, we would try to close
it a second time, accessing a function pointer that didn't exist
anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1515720
This happens on hardware without fingerprint readers on every boot; we
don't need to log anything about it, it's totally normal.
This patch is part of an initiative to reduce logging spew in GNOME
so that actual errors and important messages are more visible.
https://bugs.freedesktop.org/show_bug.cgi?id=71889
the dbus activation machinery depends on daemons taking a name on
the bus to complete activation without timeouts.
fprintd fails prematurely if there is USB bus (as found in some
virtual machine setups).
This commit moves the bus-name-acquisition code to happen before
the fail-from-no-usb-bus code to keep callers from timing out
when activating fprintd.
https://bugs.freedesktop.org/show_bug.cgi?id=57025
Pretty hacky way to detect whether the device we're handling has
been disconnected during a verify or enrollment. This should allow
us to avoid users having to wait when somebody pulls the plug.
- Use D-Bus native properties instead of a GetProperties call.
- Fix a number of front-ends by registering the right signals and
marshallers following the "done" signal argument addition
- Fix VerifyStart call in the pam module
