The state was always AWAIT_FINGER and it was never used by any driver
(except for error checking). So remove it, in particular as a correct
state change will be done after activation anyway.
The only driver with code that actually did anything based on this was
the URU4000 driver. However, all it did was an explicit state change
execution. This is not necessary, as the state_change handler is called
anyway (i.e. we now only write the AWAIT_FINGER register once rather
than twice).
Manual changes plus:
@ init @
identifier driver_name;
identifier activate_func;
@@
struct fp_img_driver driver_name = {
...,
.activate = activate_func,
...,
};
@ remove_arg @
identifier dev;
identifier state;
identifier init.activate_func;
@@
activate_func (
struct fp_img_dev *dev
- , enum fp_imgdev_state state
)
{
<...
- if (state != IMGDEV_STATE_AWAIT_FINGER_ON) { ... }
...>
}
Pass the struct fp_dev and user_data to fpi_ssm callbacks, so that we
might be able to get rid of the fpi_ssm_get_user_data(), and
fpi_ssm_get_dev() as most drivers just get those from the ssm anyway
in their callbacks.
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
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.
It seems that on faster devices, the driver can get more duplicate lines.
Without this change scan looks too stretched.
Suggested by: Thomas Rinsma <thomasrinsma@gmail.com>
New driver for VFS5011 138a:0011 and 138a:0018
https://bugs.freedesktop.org/show_bug.cgi?id=61692
[vasilykh]:
- use g_get_real_time() instead of non-portable time()
- use g_free() instead of free()
- comment out "RECV(VFS5011_IN_ENDPOINT_CTRL2, 8)"