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) { ... }
...>
}
By asserting if we have a zero line width.
libfprint/drivers/upeksonly.c:118:7: warning: Division by zero
mean /= (ctx->line_width / 2);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
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.
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.
Use fpi_mean_sq_diff_norm() for blank line detection and
fpi_mean_sq_diff_norm() for duplicate line detection.
Fixes finger presence and removal detection.
ID is just a some magic number to make fingerprint from one scanner model
incompatible with another scanner model. Get rid of "magic", declare enum
and use it.
https://bugs.freedesktop.org/show_bug.cgi?id=56956
Don't consider the scan complete unless theres at least
MIN_ROWS recorded or very long blank read occurred.
Typical problem spot: one brief touch before starting the
actual scan. Happens most commonly if scan is started from
before the first joint resulting in a gap after the inital touch.
http://lists.reactivated.net/pipermail/fprint/2009-December/001406.html
