There has been a report that a 0x0c03 was installed straight (other
readers so far have produced images that are 90 degrees rotated). There
is no way for the dirver to know how a device is installed, so for now just
make an exception.
Sensor reset code has been removed because it is not needed during normal
operation.
Calibration and frame processing logic has been improved according to
recommendations from Elantech.
Make each command a separate struct to get finer control over which
commands are called on which devices. Update ssm's accordingly. Add
sensor_reset and fuse_load commands.
Support 0x0903, 0x0c03, 0x0c16, 0x0c1a, 0x0c26
Similarly to b1ac865abd, downgrade
fp_err() to be non-fatal. A number of drivers would spit out an error
when encountering this call, but not crash, carry on and most of the
time recover.
Make sure we don't assert in those cases.
BUG() and BUG_ON() didn't use to assert, but only print an error if
debugging was enabled. This was hiding a lot of state bugs in drivers,
and transforming those into assertions causes crashes.
Downgrade the assertion to only print a warning, and hope that those
eventually get fixed in the drivers so we can re-enable them.
Closes: #77
The driver will at least need to close its hardware resources, and
free memory, so it must have had one.
This case was never actually used as can be seen from the fact that
we would assert in fpi_drvcb_close_complete() if the state was wrong
but never set it to the expected value.
Which avoids passing zero lines to fpi_assemble_lines()
"gmem.c:130: failed to allocate 18446744073709551612 bytes"
#3 0x00007fe4f6ef428f in g_log (log_domain=log_domain@entry=0x7fe4f6f3506e "GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7fe4f6f3e610 "%s: failed to allocate %lu bytes") at gmessages.c:1398
#4 0x00007fe4f6ef2ac4 in g_malloc0 (n_bytes=n_bytes@entry=18446744073709551612) at gmem.c:129
#5 0x00007fe4f8052020 in median_filter (filtersize=25, size=-1, data=0x0) at assembling.c:309
#6 fpi_assemble_lines (ctx=ctx@entry=0x7fe4f82ac3c0 <assembling_ctx>, lines=0x0, lines_len=0) at assembling.c:389
#7 0x00007fe4f805f3db in submit_image (ssm=ssm@entry=0x16c3cba360, data=data@entry=0x16c3cb9cc0) at drivers/vfs5011.c:412
See https://bugzilla.redhat.com/show_bug.cgi?id=1484812Closes: #42
Every frame stores the delta from the previous frame, in reverse mode
it stores the delta to the next frame. This causes images to use the
wrong delta while assembling in forward mode.
The broken assembling in forward mode will create a small error for
linear motion, because the delta of all frames is approximately the
same in this case. But if you move your finger, stop and then continue
moving in a single scan, the misplaced frames should be visible in
the assembled output.
This could result in false positives and verification failing.
https://bugs.freedesktop.org/show_bug.cgi?id=105027
aeslib.h and assembling.h don't need access to internal data structures,
so make them include the public fprint.h rather than the internal header
fp_internal.h.
This time, the macro didn't wrap the condition, resulting in calls
like BUG_ON(size > 100) being expanded to g_assert(!size > 100), when
what we wanted was BUG_ON(!(size > 100)).
See 9cca501650,
ff09456cf5, and egg on my face.
Remove deprecation warning that comes from an internal function, it
serves no purpose, and the function itself is deprecated.
Follow-up from commit 1f0079a274.
libfprint/drivers/upekts.c: In function ‘alloc_send_cmd_transfer’:
libfprint/drivers/upekts.c:161:2: warning: ‘strncpy’ output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
strncpy(buf, "Ciao", 4);
^~~~~~~~~~~~~~~~~~~~~~~
Replace with memcpy() to only copy the 4 bytes we need.
https://bugs.freedesktop.org/show_bug.cgi?id=106281
Remove all the headers already included through "fp_internal.h" such as
<libusb.h> and <errno.h>, include "assembling.h" and "driver_ids.h" there
as well to avoid doing it in (almost) every driver.
As this is pretty much copy/pasted in fprintd, and should instead be
implemented by whatever system actually stores the data, rather than
in a generic but not quite "fits-all-purpose" way.
https://bugs.freedesktop.org/show_bug.cgi?id=106550
Instead of having to modify both fp_internal.h to list each driver
definition structure, and core.c to add those drivers to arrays we
can loop over, generate both of those using meson.
We shouldn't need to specifically enable debug logging to get useful
data out of a compiled libfprint either, so always enable debugging
output. It will still be switched off at runtime, by default.
There are no parts of libfprint that are so resource intensive that we'd
want to disable logging. This avoids (hopefully rare) cases where
compiled versions of libfprint are distributed with logging completely
disabled, and thus can't be debugged.
nbis/mindtct/morph.c:152:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
nbis/mindtct/morph.c:176:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
nbis/mindtct/morph.c:200:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
nbis/mindtct/morph.c:222:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
https://bugs.freedesktop.org/show_bug.cgi?id=105429
libusb_free_device_list() needs to be called on the list of USB devices
obtained through libusb_get_device_list() or the list and its elements
will be leaked.
https://bugs.freedesktop.org/show_bug.cgi?id=105427
