- 03 Mar, 2021 7 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Benjamin Berg authored
-
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".
-
Benjamin Berg authored
-
Benjamin Berg authored
-
- 22 Feb, 2021 2 commits
-
-
Marco Trevisan authored
We are currently exporting such functions in the library, even though they are meant to be only private.
-
Marco Trevisan authored
Depending on the enum order is ok, but not really maintainable so better to explicitly list the states we want to listen.
-
- 05 Feb, 2021 1 commit
-
-
Benjamin Berg authored
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
-
- 04 Feb, 2021 1 commit
-
-
weilei authored
Add PID 6594 used by LENOVO
-
- 02 Feb, 2021 1 commit
-
-
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.
-
- 29 Jan, 2021 1 commit
-
-
Marco Trevisan authored
We should not pass such kind of errors to complete functions, or we'll fail the identification without ability to retry immediately.
-
- 28 Jan, 2021 19 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
We were returning an invalid type for the enroll stages, while trying to get the class from the private instance for the device driver
-
Marco Trevisan authored
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!
-
Marco Trevisan authored
Commands that are not valid for non-scan operations should be removed from queue, or these may be re-proposed forever.
-
Marco Trevisan authored
And we can properly provide a real traceback as well
-
Marco Trevisan authored
-
Marco Trevisan authored
We need to get them back to the caller function to be caught by the test suite.
-
Marco Trevisan authored
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
-
Marco Trevisan authored
-
- 27 Jan, 2021 1 commit
-
-
- 26 Jan, 2021 7 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
-