The unplug tests assume that the device is removed from the context once
they run, however we may have left the device around in a removed state
causing other tests to fail.
So isolate them in a new class where we create context and device
instances every time we run a test case.
After the driver internal duplicate check had been removed in
46669e9f53, all templates were saved with
an all-zeroes template ID.
By going through FP_ENROLL_CREATE before starting to capture, the
template ID returned from the device is taken into account again.
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
v1.94.5
* New driver: fpcmoc, supporting various FPC MOC Fingerprint Sensors
* goodixmoc: New PIDs 0x6014, 0x6094, 0x631C, 0x634C, 0x6384, 0x659A.
* goodixmoc: Support resetting device on firmware failure due to corrupted DB.
* elanmoc: New PIDs 0x0c88, 0x0c8c, 0x0c8d.
* synaptics: New PID 0x0104.
* upektc: New PID 0x2017.
* Fixed various memory leaks
* More tests
Git-EVTag-v0-SHA512: a36e4b627ffc830a78932266119b73e53921965990bd1b6cae6fd8d166b1b8e62f5a538151a74b82a2a2d83a4ab7399ed17cb2bef39441f881a38a24252e4efa
We have an issue where some symbols are exposed by both the tod library
and the public one, and this may lead to big issues like GType's being
defined multiple times.
So add a test checking whether this is working
See: 3v1n0/libfprint#1
We used to ignore leaks, and we are ending up in having various of them,
so let's make valgrind to exit with error when using the valgrind test
setup (so in CI) to catch them better.
At every action we update the device temperature, and this can
potentially lead to a failure, if the temperature is too hot.
However in such case we were failing a task that we had just stolen,
causing an error, tasks never returning and the device was left in an
undefined state.
So, just return early in case temperature is too hot, as we don't really
need to have the current task or action set at this point because
there's no active action to cancel yet.
This was causing random errors when running tests under valgrind
We ignored assertions happening on callbacks as they only raise
exceptions that does not stop the execution.
So ensure that this is happening in all the tests as synaptics was
doing already
Same as commit: be8888431
We ignored assertions happening on callbacks as they only raise
exceptions that does not stop the execution.
So ensure that this is happening in all the tests as synaptics was
doing already
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Traceback (most recent call last):
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <module>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <genexpr>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^
ValueError: invalid literal for int() with base 10: b'g9049374\n'
When opening the device, query the stored prints. This should usually
always succeed (and it should be fast). If it fails, then we are very
likely dealing with a corrupted template storage on the device. In that
case, emit the command to clear the storage in order to reset the device
and get it back into a usable state.
The kernel caches URBs to get descriptor values. Doing a reset before
starting the record ensures that we will see any descriptor reads in the
usbmon trace and can therefore correctly replay them (possibly not true
if they happen multiple times).
The code is correct, but gcc thinks the pointer is still NULL after the
call. As obvious workaround don't seem to work, just disable the warning
for now.
The code is correct, but gcc thinks the pointer is still NULL after the
call. As obvious workaround don't seem to work, just disable the warning
for now.
The internal storage of this device can get messed up by other operating
systems, so it's handy to be able to clear it.
I'm not 100% sure whether the commands I've sent to the device are
exactly what is supposed to be used (just a guess), but it did seem to
work, and it even fixed another issue I had.
Marco Trevisan (Treviño)