Comment 13 for bug 1956885

The verify fonction is synchronous here, the wait is probably the "while(!cvif_process_interrupt(MAX_WAIT_RX_IDENTIFY_TIME))".

As I wrote, when testing with fprind-verify :
"Verify started!" should happen immediately, but the libfprint code waits for fp_device_verify to return, which only happens when the finger is pressed with this driver.
The verify success message is sent during the call, so it is ignored.

https://fprint.freedesktop.org/libfprint-dev/FpDevice.html#fp-device-verify => fp_device_verify is specified to be asynchronous.
It calls the verify callback of the driver : https://gitlab.freedesktop.org/3v1n0/libfprint/-/blob/tod/libfprint/fp-device.c#L1381.
So this implies the verify callback must not block.
https://fprint.freedesktop.org/libfprint-dev/libfprint-2-Internal-FpDevice.html documents the verify method as "Start a verify operation", the "Start" is probably meant to suggest the asynchronous implementation.

"fprintd-verify -f any" (when at least 2 fingers are enrolled) prints the "Verify started!" message quickly, without waiting for the finger to be pressed.
So it seems the identify function in the Broadcom driver is different, maybe it runs in a thread.

Looking at other drivers, it seems they either do their own asynchronous code, or they use fpi_ssm_start (https://fprint.freedesktop.org/libfprint-stable/libfprint-Sequential-state-machine.html).
In the callbacks like verify, they usually send the command to the device, but then the response would be handled asynchronously.

The issue for the Broadcom driver is that you probably need to call cvif_process_interrupt somewhere, maybe in a thread. From the symbols, it seems it calls libusb synchronous APIs directly, instead of for example using https://fprint.freedesktop.org/libfprint-dev/libfprint-2-USB-transfer-helpers.html (which wrap gusb, which rely on libusb asynchronous APIs).