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.
