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.
[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.
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.
