These examples have not been ported. In addition, they are also not very
useful these days, as the demo application offers a much nicer view to
view images from a sensor.
The tests cannot work without the introspection bindings. So put them
into a corresponding if branch and also add the correct dependency on
libfprint_typelib for them to be run.
This changes the cancellation logic a bit to ensure we always deactivate
the device (equivalent to the AWAIT_OFF state in the driver). All
commands except for the deactivation command should be cancelled when an
operation is stopped, this is to ensure that the LED is turned off at
the end of an operation.
Heavily modified by Benjamin Berg <bberg@redhat.com> to port it to the
new libfprint API and adjust the coding style to follow more closely
other drivers.
This driver has a rather odd state machine and also used to mess iwth
the internal state of the image device. This code has been removed, but
is untested unfortunately due to a lack of hardware.
Most likely, this driver is not quite functional currently.
This is a rewrite of the core based on GObject and Gio. This commit
breaks the build in a lot of ways, but basic functionality will start
working again with the next commits.
We will not want to install virtual drivers by default, yet they should
be inside the "all" category. So add a new "default" category and also a
separate array for the future virtual drivers.
We will use GUsb rather than libusb directly in the future. This should
simplify a lot of the integration work and changes such as supporting
hotplugging. It will also require quite a lot of internal changes.
libfprint already uses G_DEBUG_HERE in a lot of places which requires
GLib 2.50. Also add the appropriate defines so that usage of newer API
will result in warnings.
Instead of having to modify both fp_internal.h to list each driver
definition structure, and core.c to add those drivers to arrays we
can loop over, generate both of those using meson.
We shouldn't need to specifically enable debug logging to get useful
data out of a compiled libfprint either, so always enable debugging
output. It will still be switched off at runtime, by default.
There are no parts of libfprint that are so resource intensive that we'd
want to disable logging. This avoids (hopefully rare) cases where
compiled versions of libfprint are distributed with logging completely
disabled, and thus can't be debugged.
