| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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.
|
|
|
|
Only print errors if any
|
|
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
|
|
|
|
|
|
|
|
fpi_ssm_next_state_timeout_cb simply does not exist, remove it.
|
|
Without this the signals/properties are simply missing from the
documentation, which is obviously not very useful.
|
|
|
|
|
|
In some cases it can be useful to be able to retrieve the device. Add
the corresponding getter to do so.
|
|
|
|
search paths
|
|
|
|
It will trigger firmware to do some activities, remove it in device open
and device probe.
|
|
Upstream systemd/udev is pulling our autosuspend hwdb, so if udev is new
enough, then there is no need to install the file. As such, add
auto-detection logic for the scenario.
This also changes the name of the option and the type to "feature".
|
|
|
|
|
|
We are currently exporting such functions in the library, even though
they are meant to be only private.
|
|
Depending on the enum order is ok, but not really maintainable so better
to explicitly list the states we want to listen.
|
|
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
|
|
Add PID 6594 used by LENOVO
|
|
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 should not pass such kind of errors to complete functions, or we'll
fail the identification without ability to retry immediately.
|
|
|
|
|
|
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.
|
|
|
|
|
|
The idea of the test was just checking what happens when we're opening a
device multiple times while a first request is still going.
However, it actually ends up also checking the previous commit change
because without it we'd stop the close iteration before the device is
actually closed and stop the open iteration before the device is
actually opened, leading to an infinite loop.
|
|
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.
|
|
|
|
|
|
We were returning an invalid type for the enroll stages, while trying to
get the class from the private instance for the device driver
|
|
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!
|
|
Commands that are not valid for non-scan operations should be removed
from queue, or these may be re-proposed forever.
|
|
And we can properly provide a real traceback as well
|
|
|
|
We need to get them back to the caller function to be caught by the test
suite.
|
|
If trying to identify a print not in the storage we emit data not found
error, this can be helpful to do further fprintd testing too
|
|
|
