Two changes to the verify loop, both from measurement on the daemon.
The rising edge sent events 5 and 7 from the same capture and got two verdicts
back from one image -- rej rej, -11 -11, MATCH MATCH. Event 5 reaches the
matcher here as well as event 7, so the second REPORT_EVENT was 250 to 300 ms
of redundant work on every press, on the frame where speed matters most.
Authentication now sends only event 7. Enrolment keeps event 5, where it is the
sample trigger rather than a duplicate.
And the frame that detects the finger is the finger landing: partial contact,
and the frame that rejects most often -- across the real runs matches came at
frame 3, 5 and 8 of a press, and a quick tap is one frame. So on the rising
edge the daemon captures once more, about 50 ms later, before reporting, and
the matcher's first look is at a settled finger.
The rescan-budget experiment is reverted. At the stock budget every
non-matching frame answered -11, for the enrolled finger and the wrong one
alike, while matches landed exactly where they did at rescan=0. The budget
relabels a non-match; it does not make the trustlet try harder. Under the press
rule the two are functionally identical, and rescan=0's terminal rejection is
the cleaner label.
Two problems from a real attempt, one mine and one the tool failing to explain
itself.
A sample is taken on the RISING edge only. Holding the finger down produces no
further touch events however long it stays there, so a run with the finger
almost permanently down collects one sample: 55 finger frames across 60, three
touch events, two samples accepted. The loop now says which state it is in on
every line -- press, hold, or LIFT -- shows accepted-of-total as it goes, and
calls out a finger that has been held for several frames, because that is the
state where nothing is happening and nothing on screen said so.
And the total is now read from the config instead of inferred. `rem` is
reported after the sample is processed, so the first reading of a healthy
enrolment is already 9, and a session that takes the first reading as its total
is permanently off by one -- it reported "1 of 9 accepted" when two samples had
been accepted out of ten. common.max_enrolling_samples is stated explicitly in
the generated config so both sides agree on the number rather than one of them
guessing.
Also recorded: not every press is accepted. The third touch of that run
reported the same count as the second, which is the algorithm rejecting a
sample, and is normal.
A three-tap enrolment declared itself complete. The transcript says why:
frame 2: metric=308 FINGER ev5 rem=10
frame 3: metric=187 ev6 rem=0
samples: 10 of 10 accepted
The release event never enters do_enroll, so its response leaves
samples-remaining untouched at 0 -- which is indistinguishable from "none
remaining, you are finished". The session believed it, stopped after one press,
and called SAVE_DATA on an algorithm holding no template. That answered -1 and
wrote nothing, so the store was undamaged, but only by luck: the guard meant to
prevent a partial save was itself satisfied by the bogus count.
A reading is only meaningful when it came from the event that runs the enrol
path, and nothing about the value says so -- the caller has to. Observe now
takes that as an argument. Two further guards: a FIRST reading of 0 is an
unpopulated field rather than a finished enrolment, and the count only ever
falls, so an increase is noise.
Verified by mutation: trusting the release event's count, and accepting a
leading zero, each fail the suite.
Fingerprintd:Engine is the policy the trustlet cannot supply. It never polls
for a finger: the normal world captures a frame, decides whether a finger is
there, and tells it. So finger detection, edge reporting and the accounting all
live out here, and they are the parts most easily got wrong in a way that reads
as bad hardware.
Baseline refuses to be a fixed threshold. The capture metric is per frame, so
it scales with how many frames a capture asks for, and it drifts upward while
idle -- an early session read "18 -> 24 with a finger" as weak detection when
the values were climbing regardless of what was on the sensor. The floor is the
maximum of the idle samples, and an uncalibrated Baseline calls nothing a
finger rather than inventing a threshold.
TouchTracker keeps the two modes apart. Enrolment reports touch on the rising
edge and release on the falling one and nothing while held, mirroring stock,
whose entire enrolment trace contains no image-ready event; emitting one per
held frame feeds the algorithm near-duplicate images from a single press.
Authentication does want it, because event 7 reaches the matcher
unconditionally.
AuthTally exists to stop two counting mistakes. Only a terminal verdict is an
attempt -- counting rescan frames as rejections is what turned an 8-for-8 run
into an apparent 8-of-39. And a press that ran out of frames without reaching a
verdict is UNDECIDED, not failed; treating it as a failure is the same error one
level up, which is why decided presses are counted separately.
The tests replay the three recorded runs in order rather than as totals,
because press structure only exists in the order. That makes the per-press
claim re-derivable here instead of quoted: the enrolled finger matched on all
five presses although five of its twenty frames did not, the wrong-finger
control matched nothing, and on the stock-budget run five of ten presses
reached a verdict and all five matched.
Verified by mutation: counting undecided presses as decided, using a baseline
before calibration, emitting image-ready during enrolment, and taking the first
idle sample as the floor each fail the suite.
