It is completely fine for a capture to have a low quality or fail. No
need to warn about this. Main reason to remove it though is so that
recordings that contain such a message do not trigger a failure.
If we delayed the suspend(/resume) call, then the circumstances may have
changed. In particular, an active action may have completed already
which means that the driver handler should not be called anymore.
These delayed calls are pushed into the mainloop for consistency.
However, they should run immediately and not be delayed, as such, it
makes sense to run them at a higher priority.
This actually solves an issue inside the CI where an URB reply is played
back even though it should be cancelled by the client.
We re-aquire the critical section at the start of the callback, however,
it needs to be dropped again (or not taken) if the interrupt transfer is
resubmitted.
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).
Having this should at least give us a slightly better idea about the
version that the user has installed. Obviously it is still not very
accurate (maybe a git hash would be good if available?), but it should
still be helpful overall.
Given that we won't go in the past, it's better to be explicit in
using versions for symbols so that all new symbols will be added to the
latest listed release, while others won't be moved from where they are.
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.
The API should return the recognized print, even if none of the prints
given in the gallery (or the one passed to verify) matched. Without this
the garbage-collection of left-over prints does not work, causing issues
after reinstall.
Fixes: #444
In commit 5c28654d9 ("goodixmoc: Fix print template parsing") the length
check for the verify and duplicate check responses by requiring two
extra bytes at the end of the message.
There were also issues in other places where the length was not checked
correctly, including a scenario that could cause a read beyond the end
of the buffer.
Related: #444
Benjamin Berg