Add ChangeLog generation makefile target.
Group all copyright notices in AUTHORS.
Update some doxygen comments, and allow fp_dev_close(NULL)

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.

This adds fp_exit() to the public API, intended to be called while the
driving app is shutting down.

Pavel Machek and Timo Hoenig agreed to relicense their work. Thanks guys,
I look forward to working together.

aes4000 detects fewer minutiae and hence returns lower scores.

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.

For example, AES2501 returns images that vary in height.

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.

Also enable it in the default development build

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.

Make it easier for application developers, don't have to care about this
level of abstraction which we're intending to make superfluous to them.

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.

Otherwise it heats up, and verify retries fail because we didn't end the
session.

Install fprint.h header
Include headers in distribution
distcheck fixes
Include and install pkgconfig file

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.

Add accessor functions to the various structures

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.

Part 1 of many. Remove some unused/pointless code, and made some code
static.

uru4000 works splendiferously (YAY!)
aes4000 is going to need some work though :(

mindtct is mostly as-is for now, with just a couple of bits ripped out.

Creating by dimensions is likely not useful now that we can infer image
size from a device in question.

Drivers now specify the size of the image they provide, and theres an API
so that you can get the size of an image before you capture it.

Initially supports flipping and colour inversion

Also added new example: img_capture