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.
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.
Some scanners provide hardware assistance in frame assemling, i.e.
horizontal and vertical offset to previous frame is provided. This
commit improves code to utilise that assistance. Sensors without
hardware assistance will use software algorithm, which was also
improved to do search in horizontal direction.
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
Wait for 3 empty frames before stopping the scan
The driver used to stop the scan immediately after an empty frame
(by checking for hist sum == 0), but it is possible to get empty
frames in the middle of the scan due to low finger pressure.
Waiting for 3 empty frames stop the driver wrongly aborting the scan
too early.
https://bugs.freedesktop.org/show_bug.cgi?id=56715
I want to offer the ability for an application to view a binarized
version of a scanned print. This lead onto a few changes:
1. Store minutiae and binarized data inside fp_img
2. Move resize code to the capture path, it previously happened much
later.
3. Add fp_img_binarize() to return a new image in binarized form.
4. Add a BINARIZED_FORM flag to prevent an image being binarized again.
In future, it would be nice to be able to binarize without detecting
minutiae, but this involves some work on the NBIS interaction.
