As per recent changes, drivers can just avoid implementing verify vfunc
unless the driver has specific commands to do it.
So let's just drop the duplicated code in drivers that have the very
same code path for both identification and verification.
In case a device has not support for verification through an explicit
verify function, the verification can still be implemented using
identification with a gallery of a single print.
In fact that's what most of drivers these days do it, so let's just
avoid to them to handle this duplication unless a driver has really some
specific commands to do it.
Same MOC protocol family as the already-supported 27c6:6384/631C.
Verified against real hardware: open, enroll, verify, identify and
delete all succeed. Dell's own driver .inf for this PID (extracted
from Goodix-Fingerprint-Sensor-Driver_T2VK3_WIN64_40.10.1.100_A05_01.EXE)
confirms it uses the plain (non-SecureFingerprint) MOC protocol.
If the reader does not respond, currently the plugin segfaults.
The error should be handled gracefully.
With this change, an error is printed instead of crashing:
failed to claim device:
GDBus.Error:net.reactivated.Fprint.Error.Internal:
Open failed with error: Can't get response!!
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Add USB PID 0x2020 (NB-2020-U) to the nb1010 driver's id_table.
The NB-2020-U is an embedded variant of the NB-1010-U using an
identical sensor die (confirmed by independent teardown reports from
System Plus Consulting/Yole Group). USB endpoint layout, command
protocol and image format are identical between both devices.
Tested on a Fujitsu notebook with integrated NB-2020-U reader
(USB ID 298d:2020): device enumeration, finger detection polling
and image capture all work correctly with the existing nb1010
driver code.
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.com>
In test mode, dynamically load libraries in well known locations that can
allow to override the libfprint behavior.
It would still be possible to potentially inject code by replicating the
distro build directory and adding a library there, but if one is able to
access there, they would already be able to access any path.
Plus the env variable check is still there, so again they would need to
be able to change the fprintd environment
Rather than just do it in production if set, make it more difficult to
potentially inject the test mode.
So rely on a weak definition of fpi_device_emulation_mode_enabled() that
can be only set externally
Drivers may do some adjustments in test mode, initially we wanted to
reduce this to the minimum but the usage of `FP_DEVICE_EMULATION`
exploded, so move this instead into a properly defined variable that:
- Uses GLib compiler optimizations
- Is read just once per process
- Cannot be misused
As per commit bad930503c the test data is way bigger than it used to
be, so the test duration is longer.
Thus increase the timeout not to have failures
DT_RUNPATH is intentionally searched after $LD_LIBRARY_PATH.
-Wl,--disable-new-dtags switches to the old DT_RPATH tag, which is searched
before $LD_LIBRARY_PATH. So the embedded paths in the build binary will now
win over whatever is in the environment.
Not breaking builds.
