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
We can only create the udev rules file when we're not cross-compiling,
so allow people to disable updating the file when building from
tarballs.
If you run with --enable-udev-rules=no and the
60-fprint-autosuspend.rules doesn't exist, you're on your own.
Instead of hardcoding whatever the new fashion is every few months, which might
even differ between distributions, just put the rules where udev says we should.
https://bugs.freedesktop.org/show_bug.cgi?id=50426
The function fpi_im_resize copy the new resized image into old fp_img
instead of newimg so, new image is empty and often it generated a
segmentation fault error.
On function fp_get_next_timeout if exist fprint timeout or libusb
timeout the function return the smaller of they.
But if one of that not exist and have a smaller value the function
return a timeout that not exist.
The libfprint library is generally built with C calling conventions.
Which makes it difficult to link to C++ programs as it is.
This patch adds the support for linking with C++ code - by telling the C++
compiler to use C calling conventions for libfprint functions.
Reported-by: Guus Ellenkamp <guus@activediscovery.net>
Signed-off-by: Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com>
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
Check all the drivers for one that'll drive our device in
question, and prefer ones that have a discover() method that runs
successfully to a driver without such a method.
This allow drivers to both reject devices (if 2 drivers handle
the same USB IDs), or a single driver to handle variants of the
same device (through the devtype out value of the discover method).
Most fingerprint readers can be suspended safely, so use
the udev rules to autosuspend them when they appear.
The script itself contains whitelists and blacklists.
When imaging support is required, we prefer to use gdk-pixbuf,
as it's already on things like Live CDs.
Also fix the examples building against the system libfprint.
New DigitalPersona devices have a new firmware. We now use a search
scheme to find the encryption byte, by examining known locations
in the firmware until we find something that we recognise.
A subssm will be executed, and upon completion the parent state machine
will either be advanced to the next state or aborted with error, depending
on the outcome of the subssm.
Also add some debug messages.
Add timeout mechanism as an asynchronous equivalent of sleeping (uru4000
needs this).
Start implementing polling infrastructure which also accounts for pending
timeouts. We don't expose file descriptors yet, but this is a start.
[dsd@gentoo.org: some trivial changes:
fixed some warnings
fixed fp_img memory leak on error
renamed endpoint constants (calling a bulk endpoint 'ctrl' is confusing,
as a control endpoint is something different)
]
After lot 713, Microsoft fingerprint readers changed. The new version
comes with a new USB product ID and a challenge-response authentication
scheme where the device challenges the authenticity of the driver.
An independent third party produced documentation on the computations
needed to convert a challenge into the correct response, and I then used
this documentation to produce a clean-room reimplementation of the
authentication scheme.
bz threshold is now 10 (instead of 15). I think it is ok for the moment.
If we manage to get higher image quality in the future, we'll change that.
max_frame is set to 350. 150 was too low => incomplete fingerprints
the driver was designed to stop the acquisition as soon as it gets a blank
frame (=> incomplete fingerprints). Now it waits to have at least 50 blank
frames before stopping.
This is an active capacitance swipe-type device similar to but smaller
than the AES2501.
Image processing performance is good but matching performance is not so
good. The bozorth3 matcher needs tweaking in order to better cope with
small sets of minutiae.
With a lowered threshold, matching performance is good enough for now.
Fix the functions to conform to the documentation: -1 means non-imaging
device, 0 means variable. Internally, -1 is used to represent variable
height (to be noticably different from the memset-imposed default of zero).
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.
The UPEK TouchChip is an active capacitance imaging device with a
press-type sensor. It also has image storage capabilities which will
hopefully be accessible through libfprint in the near future.
This device can be found in the Samsung P35 laptop.
With the multiple register writing code, the image quality is much
better. It's trivially easy to get a match score of 100, and 200 is
possible with a little effort. Remove the lowered match threshold.
Instead of writing each register in a separate USB transaction, we now
write up to 16 at once.
This drastically improves scan image quality due to reducing the amount of
time needed per iteration of the sampling loop (sending 1 USB transaction
per iteration instead of 7).
aes2501 can be mounted 180 degrees rotated (this happens on most part of
laptops), so driver should detect whether sensor is 180degrees rotated
and assemble frames in right order.
This driver works quite nicely. Seems a little too sensitive though (too
much black in the standardized image, not enough ridge gap definition).
Processing results are quite good, but you need a good enrollment image
(i.e. long!). It's best to get such images by pressing harder than you
might think necessary and swiping slowly.
Added new API functions to obtain images, even when scans are bad, perhaps
a useful way to show the user just how good/bad the scan actually was.
Drivers and examples updated accordingly.
mindtct appears to completely ignore the pixels-per-mm input parameter
(ippmm). When processing AES4000 images, the binarized image is
completely mangled and a lot of ridge information is lost.
Resizing the AES4000's small images results in a huge imaging performance
gain.
We use imagemagick for the resizing, as it's resizing code resamples the
image too (smoothing it out), which further improves performance.
The windows driver takes one sample at the previous register settings
and then changes some registers before resamping (and getting much better
images). The exact changes that it makes seem to vary, perhaps based on
the histogram.
Anyway, this is an approximation of the settings used for the 2nd sample
which should help matching results.
My UareU4000 device isn't working properly -- only seeing an all-white
image and no finger-on detection, however I think this code should work
for working devices.
When we include the await_finger_off procedure (i.e. set mode 12), the
current power-up code is unreliable - no 56aa interrupt arrives sometimes.
Comparing the F0 data and hwstat at this point between a working and a
non-working run yields no differences.
Work around this issue by retrying power-on 3 times.
While testing the new code on my MS keyboard, I found some strange
conditions where occasionally, the device will stop providing images
headers until it is replugged.
Detect and work around this when it happens.
This should improve driver stability somewhat. Powerup problems seem to
happen when we receive 3 unrelated interrupts while waiting for the
power-on interrupt, so let's assume that the device can only buffer 3
interrupts, and when the buffer is full, it discards new ones.
When we detect a possible buffer overflow, ask the caller to retry the
operation.
Also, saw the interrupt of death a few times, so add in a warning when
this happens. Haven't seen it since handling interrupt overflows though.
Add concept of "discovered prints" and flesh out the API. A discovered print
was found based on file name but has not been checked for file integrity,
and of course there is no guarantee that it is usable when you try to
use it later (might have been deleted, etc).
The .fprint directory structure was changed - instead of using mnemonics
like "rind" we use their numeric value in the fp_finger enum as the filename.
Drivers can now offer a discover function, and are expected to offer the
device devtype during discovery, without accessing the USB device. Hmm.
Maybe we'll have to change that later...
Drivers now have an ID number. These will be assigned by me and documented
on the wiki. 0 cannot be used.
Drivers now define a devtype for each device they initialise. This is to
cope with the situation where a driver can support varying devices where
their print data is incompatible (i.e. image scaling is totally changed).
This doesn't apply to any existing supported devices.
Print data no longer includes driver name, and includes driver ID instead.
Paths to saved print data now include driver ID and devtype, and no longer
include driver name.
APIs exposed for converting a print_data into a blob which can then
be loaded back again later. Useful for systems who don't want to use
my simple storage system (which is only aimed at a single user).
File format is now defined and will be documented on the wiki. The header
is larger as we can no longer rely on directory paths in all scenarios.
Print data compat check now checks devtype and driver ID.
The basic model is that image drivers declare a fp_img_driver structure
rather than a fp_driver struct. fp_img_driver will contain primitive imaging
operations such as 'scan finger and return image'. The imgdev layer will
generically implement the primitive fp_driver operations, and the imgdev
layer will fix up the enroll/verify/etc pointers at driver registration
time.
Removed const from all fp_driver declarations, as these are now modified
dynamically in the case of imaging drivers.
Prints can now be saved to disk (but you currently must classify which
finger they are) and you can load them later.
Added 2 simple example programs to demonstrate this.
Convert enrollment function to return a signed integer, which is negative
on error or corresponds into fp_enroll_result otherwise.
Now we can treat a 'FAIL' condition differently from an actual error: fail
means that enrollment didn't complete because the data was nonsense or
whatever (e.g. scanned a different finger for each stage?).
Updated upekts accordingly.
This completes an enrollment implementation for the upekts driver.
It's based on code from libthinkfinger, but as there seemed to be many
unknown details there, I spent some time analysing the bus messages in
more detail and have effectively rewritten almost all of the borrowed code.
Note that libthinkfinger is GPL licensed, so that reflects on this code too.
At release time I will ask them if they are OK for me to relicense it.
upekts will need to know when the first enrollment stage is attempted for
the first time, so add an __enroll_stage counter which actually indicates
the next stage to enroll. -1 is a special value and it means 0 is next *and*
it is the initial attemt.
Added more debug output to the enroll handler.
Added new fp_enroll_status codes for too short or uncentered scans.
Changed the print_data allocator to consider the device rather than the
driver, this feels more natural. Added missing return value.
Make fp_enroll_status codes start at 1. 0 can now be used as a
special/temporary value by the drivers. Also check that we aren't exceeding
the number of enroll stages.
Also add a missing exit() call to the verify example and update for the
above.
