rescan=0 made every frame terminal, which is what stopped a wrong finger from
hanging the client -- but it also disabled the trustlet's own "image not good
enough yet, try again" answer, so a marginal first frame became a hard
rejection. In real use that showed as a quick tap of the enrolled finger
answering verify-no-match: one frame, rejected. Matches land at frame 3, 5, 8
of a press; the first frame is the finger landing.
The alternative is to let the trustlet keep its rescan budget and handle the
wrong finger where it actually manifests, at the press level: a press that
lifts with no terminal verdict is reported as no-match. The trustlet then
answers -11 on marginal frames instead of rejecting them, and the press keeps
going until it matches or the finger lifts.
A knob rather than a decision, because the trade-off is measured, not assumed:
under the stock budget seven of nineteen correct presses ended undecided at the
old 500 ms frame rate, and whether the faster loop closes that gap is the
question the next runs answer.
Jorijn van der Graaf
93ab8570e0