The irq handler may already be stopped if stop_irq_handler is called. In
that case, we should immediately call the handler rather than just never
calling it.
This fixes deactivation when the device is unexpectedly unplugged.
Closes: #355
While meson suggests to always use 'library' this leads to some unwanted
behaviors when it comes to generate pkg-config files for it, as they
will include `Libs.Private` / `Required.private` fields that should not
be really part of a shared library as libfprint is meant to be used.
There are two variants one with storage and identify support and the
other without storage.
It implements the following commands:
* INSERT id
* REMOVE id
* SCAN id
* ERROR error-code
* LIST (returns saved print)
The INSERT/REMOVE/LIST commands are only available in the storage
driver. The SCAN command emulates presenting a finger.
These commands can be send ahead of time, and will be queued and
processed when appropriate. i.e. for INSERT/REMOVE that is immediately
when possible, for SCAN/ERROR processing is delayed.
The LIST command is always processed immediately.
Note that only a single command can be send per socket connection and
the command must be send in a single message. The socket will be closed
after the command has been processed.
Co-authored-by: Bastien Nocera <hadess@hadess.net>
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Instead of repeating the same code in both the virtual-image and the
virtual-device drivers, implement a class to handle the socket listening
an data reading.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
This solves various problems:
1. It stays the same also if some drivers have been disabled
2. It uses a stable path for being imported by systemd
3. It is still checked for its validity by tests
4. It can be auto-generated using a simple command
When building in big endian architectures some device tests will fail,
as per this we're pretty sure that most of the drivers are not ready
to work in big-endian architectures.
Since we're aware of this, better to just stop supporting those drivers
instead of having each distribution to handle the problem.
So, add a list of supported drivers that is filled depending the
architecture type we're building on. Keep continue building those
drivers since we want to at least test-build them, but do not expose
them as libfprint drivers, so if a device in the system uses any of them
will be ignored.
At the same time, we keep track of the problem, so that we can fix the
drivers.
Related to #236
The change to print a warning (for testing purposes) from commit
944e0d0383 (udev-rules: Print warning if an ID is supported) was
incorrect because it prevented duplicated to be suppressed if a device
is listed by two independent drivers.
Add a new test that checks that the unsupported list is not out of date.
As the wiki can be edited at any time, add this as a further optional
check into the CI pipeline.
As we are shipping a hwdb file now, we cannot have a collision with the
old libfprint version. Also, we are going to pull these rules into
systemd and they will not be installed via libfprint in the future. As
such, collisions will not happen again and it makes more sense like this
for systemd.
We want systemd to pull our hwdb. In order to ease this, always build
the hwdb file, even if it is disabled.
Once systemd has merged the rules, downstream should turn off the rules
in libfprint. The default in libfprint will also be changed to not build
the hwdb (udev_rules option) eventually.
We only use the rules/hwdb to enable auto-suspend. So, instead of
shipping our own rules, we can just use the existing autosuspend rules
and ship a hwdb that sets the appropriate flag.
Closes: #336
