Four matches, each followed by a template save, then five consecutive failures.
Jorijn asked whether it was user error. It was not.
Over one evening the harvest folded 185 frames into a template whose
max_sub_template_num is 96, and the template went from matching ten presses out
of ten to failing five in a row. The frames one press contributes are
near-duplicates of a single image, so folding eight of them per press does not
add coverage: it spends the template's slots on one finger position and evicts
the diversity the enrolment put there. Stock's roughly forty-six updates in a
session are spread across many separate presses, which is where diversity
actually comes from.
So one fold per matched press, which also needs no extra capture at all because
the matching frame is already inside the trustlet. Eight remains available for a
deliberate experiment.
The snapshot directory was resolved from $HOME while the script is run under
sudo, so every snapshot landed in /root/fp6-backups and looked, from the user's
shell, like it had never been taken. That is the one thing that would have made
this unrecoverable, and it was caught only because the restore was needed. It
now resolves the invoking user's home.
CONFIG=<path> copied the file to /tmp under its own basename, while the remote
half installed /tmp/fingerprintd.json. A config named anything else therefore
left the PREVIOUS deploy's fingerprintd.json in place and installed that, while
printing ">> config installed" either way.
It went unnoticed until the printed config hash did not move after a deliberate
change, which is the only reason the hashes are printed at all. An experiment had
already been deployed against the wrong config by then.
The file now crosses under a fixed name, and a deploy with no CONFIG removes any
stale one on the phone rather than leaving something for a later run to pick up
by accident.
Jorijn worked out the technique and it changes what every number in this project
means: "press and LIFT (quick tap) is wrong, holding the sensor until it gives
the result is a 100% success rate."
The logs agree, on a properly controlled comparison. Same template, same
session, learning off for all four blocks, only the technique differing: tapped
4/15 and 3/15, held 15/15 and 15/15.
The frame data says why. Over every frame this project has a verdict for, split
at 2.5x the idle floor:
full contact, interrupt settled 78/175 = 45% match
full contact, interrupt asserted 28/142 = 20%
partial, interrupt settled 1/9 = 11%
partial, interrupt asserted 0/53 = 0%
A tap is caught while the finger is still arriving or already leaving. Such a
frame is not a hard verdict waiting to happen, it is a wasted one: with the
rescan budget at 0 every frame is terminal, so its rejection ends the press. 62
partial frames produced exactly one match between them.
So the tracker becomes a Schmitt trigger. A press now STARTS on settled contact
and ENDS on the finger leaving, which means a frame taken mid-landing produces
no event at all rather than a false rejection. A press that never settles simply
yields no verdict and the loop waits for the next one, which is an honest try
again. Enrolment is untouched: it passes one threshold for both and keeps its
own sample-quality gate inside the trustlet.
fptrial.sh now says hold, and defaults to fifteen presses. Instructing a tap for
its whole life is what quietly made every rate this project has quoted a worst
case, and a tap is not a case the product has -- nobody taps a phone sensor and
walks away, they rest a finger until it unlocks.
Learning rewrites the template in place, which means a rate that climbs over an
evening has three explanations and the numbers cannot tell them apart: the
template got better, the sensor got wiped clean, or the user learned where the
sensor likes to be pressed. Jorijn named the second and third while the numbers
were still going up. All three move the same way on the same time axis, and the
first trend run had no way to separate them because no earlier version of the
template survived.
A snapshot makes the paired test possible. Measure the learned template, restore
the older one, measure again within the same session -- the sensor is equally
clean and the user equally practised across both halves, so the only thing that
differs is the template. A rate that falls back on restore is learning. A rate
that stays up is not.
Restore stops the daemon before swapping the files and brings it back with
learning off, because the trustlet caches the template in memory once loaded and
because a restored template that immediately starts learning again is not a
control.
Two changes to the measurement, both about not wasting a finger.
The wrong-finger control is off by default now. Across every run this project
has made the wrong finger has matched zero times out of forty-odd taps; the
question that is still open is the false-negative rate, and each control tap
spends a press that could have measured it. Pass a count to put the control
back, and the summary says plainly when it was not run rather than printing a
zero that reads like a result.
And a trend run now reports how many frames learning folded, out of the daemon's
own transcript, alongside the container size. Without that a run cannot tell
"learning fired and did not help" from "learning never fired" -- which is exactly
the confusion that let the first trend run measure a static template three times
and look like a result.
Default trial length goes to fifteen taps, since dropping the control freed the
presses and ten was too few to separate three-in-ten from five-in-ten.
Measured 2026-09-04: the trustlet's duplicated-finger check refuses to re-enrol
a finger it already has a template for -- 0 accepted of 7 presses, rc=0 on each,
while a never-enrolled finger progressed normally. Re-enrolment adds a template
and there is no trustlet-side remove, so a measured finger's old template has to
go before it can be enrolled again.
wipe does that the way it has been done by hand twice: backup first, daemon
stopped so the trustlet reloads from the store, only the template containers
removed, the group index kept because deleting it risks the RPMB anti-rollback
counters going stale, the name map cleared, then a restart and the sizes.
enrol checks the name map and refuses a finger that is already there, pointing
at wipe, so the refusal cannot be mistaken for bad pressing again.
A refused enrolment sample is one of two things: an image the algorithm saw and
turned down (rc=0, samples remaining unchanged) or an error the trustlet never
got past (a negative rc). The touch line printed the count and the fid but not
the rc, so a run of twenty-two refusals in a row said nothing about which it was.
It does now.
EXTRA=... on deploy-dev.sh appends daemon flags, so a diagnostic session can
come up with --ta-log without editing the script or the unit by hand.
Nothing is packaged yet, so the binary, the scripts, the module load, the
persist mount and the transient unit all live in places a reboot wipes. That is
deliberate -- a reboot leaves a stock phone rather than a half-installed daemon
-- but its cost was a list of manual steps in a journal handoff, and the second
reboot of the day showed what that costs. The list is now a script.
Two things it gets right that a first draft did not. The readiness check is
scoped to the current systemd invocation: the journal persists across restarts
and reboots, so grepping the whole unit history matches the previous run's ready
line and reports the daemon up while the session is still coming up on the
worker thread. And the binary is copied under a new name and swapped in with mv
after the unit stops, because a running executable cannot be overwritten and
scp reports that only as "dest open: Failure" -- which a retry loop turns into
six identical failures instead of one clear one.
Verified from a freshly rebooted phone and again over a running daemon.
Learning rewrites the template on every matched press, so run two is not a
repeat of run one and an A/B against a moving template is not an A/B. The order
is the measurement:
enrol a fresh template at 20 samples with no position prompts, which is also
the outstanding replication of the best result this lane has seen
base learning off: the clean number for that template, and the only figure
comparable to every rate already recorded
trend learning on, three times: the rate should climb, with the container
size as an independent witness that it is the template moving
A rate that climbs while the body grows is learning. A rate that moves while the
body does not is noise, and the daemon's own learn: lines say which. Run one of
the trend is not evidence that learning helped; it starts on the template the
baseline ended on.
One limit the script states rather than letting someone discover it: learning
only fires on a press that matched, so a template that never matches never
improves. That is why the protocol re-enrols instead of building on a template
already measured at 0 of 10.
pos() was eval'ing over the script's positional parameters from inside a
function, where $1 is the function's own argument. So `pos 3` printed "3" and
`pos 10` printed "100": every run this script has ever driven printed sample
numbers where positions should have been.
That rewrites an earlier conclusion rather than just fixing a bug. No enrolment
on this device had ever been guided, including the one that produced the best
template measured so far -- its spread came entirely from the config's overlap
band refusing near-duplicates, not from anything this script said. The
paired-test attribution drops a contributor, and the 30-sample run becomes
directly comparable to it because both were equally unguided.
Prompts are therefore opt-in now, behind FPENROL_GUIDE=1. The first run where
they actually fired steered the finger to edges, tips and hard rolls, needed 74
presses for 30 accepts, and produced a template that matched 0 of 10 taps.
Prompting a user toward positions they never use in a real tap builds a template
of positions they never use in a real tap. The default is the instruction that
worked: press as you would to unlock, and let the refusals move you.
The stage count comes from the daemon's num-enroll-stages property rather than a
second hardcoded 20.
Jorijn asked whether the sample count is ours to control and whether more
samples would help. It is -- and the config dump says something more useful.
Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six
keys we were leaving entirely to the trustlet's built-in defaults:
min_enrolling_coverage_threshold 70
min_enrolling_quality_threshold 20
enroll_overlap_min_area 60
enroll_overlap_max_area 80
enable_duplicated_finger_checking on
max_extral_enroll_low_quality 16
Those defaults accept anything, which is how ten quick taps in one position
became a stored template. The overlap bounds are the mechanism that matters:
a sample must overlap the previous one by 60 to 80 percent -- more means the
finger did not move, less means a gap -- so the algorithm now refuses the
same-spot sample instead of storing it. Sample count alone would have stored
twenty near-duplicates rather than ten.
Deliberately left out: min_identify_quality_threshold and
min_identify_coverage_threshold. Those gate matching rather than enrolment and
would reject exactly the landing frames the 1.5x detection threshold exists to
catch. One group of variables at a time.
fpenrol.sh grows to twenty positions, and its rejection message now says to
move rather than to press harder, because the enforcement and the guidance
finally agree on what a rejected sample means.
The threshold change is the first thing to move accuracy. Labelled protocol,
enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven
of fifteen presses now get two or more frames where none did before, and the
landing frames the old threshold discarded turn up in the transcript at 207,
213, 242 and 284. Wrong finger still 0 of 5.
It also explains the latency asymmetry Jorijn noticed. A match ends the loop
the moment it happens, mean 1317 ms. A no-match waits for the finger to lift,
mean 2190 ms, because a later frame in the same press may still match -- and
they do, at frames 3, 5 and 8. That is the press rule working, not a fault.
What the same run says about the template is worse than the loop ever was. One
press produced eight frames at full contact, 362 to 367, and every one
rejected; another produced six. Roughly one frame in seven matches, against the
47 to 75 percent the journal records for the template the research harness
enrolled. The first template here was ten quick taps in about one position, so
the algorithm was handed ten near-duplicate images of one spot.
fpenrol.sh enrols with a different contact position per ACCEPTED sample --
centre, left, right, tip, joint, rolled either way -- driven by
fprintd-enroll's own per-stage output rather than by counting presses. Enrol as
a SECOND finger so both templates coexist and the comparison holds the loop
constant; the trustlet reports which fid matched, and the daemon's map turns
that back into a name.
Labelled baseline on the proven loop, quick taps only: enrolled finger 2 of 10,
wrong finger 0 of 5. Every press was one frame.
The rising-edge frame costs ~700 ms because it runs the matcher twice -- event 5
and event 7 on the same image, two verdicts back. A human tap is over before a
second frame can exist at that cost. Keeping only the touch event keeps what
every recorded match followed, halves the rising frame, and may be the
difference between one frame per tap and two. It is a single variable against a
labelled baseline; if the rate drops, it comes out.
Also fixes fptrial.sh's latency column, which was all zero: busybox date has no
%N, so it reads /proc/uptime instead.
Thirteen real fprintd-verify runs produced four matches and nine misses and no
rate, because nothing recorded which finger each run used. This script runs the
protocol -- N quick taps with the enrolled finger, then N with a different one
-- tells the user which finger and which tap they are on, and records the label
and the wall-clock latency from prompt to client result per tap. The daemon's
transcript has the frames; this has the labels. A loop change is measured
against this, one variable at a time.
The probe becomes the thing the plan was for. Three threads: the supplicant
services QTEE's callbacks; the worker owns the sensor rail, the QTEE session
and the trustlet and is the only thread that ever invokes it, so every
enrolment and authentication is serialised by construction; the main thread
runs the GLib loop and speaks fprintd's own D-Bus interface, never touching
the trustlet directly.
Session is the bring-up from a cold /dev/tee0 to a calibrated sensor, plus the
enrol and verify loops as methods that take a cancel flag and progress
callbacks. Worker is a job queue on a pthread with an 8 MiB stack -- musl's
default is 128 KiB and the session keeps request buffers on the stack. Results
come back through g_idle_add so signals are emitted on the thread that owns
the connection.
net.reactivated.Fprint is implemented rather than wrapped: Manager with
GetDevices/GetDefaultDevice, Device with Claim/Release, EnrollStart/Stop,
VerifyStart/Stop, ListEnrolledFingers and the three Delete variants, the three
signals, and the five properties. Owning fprintd's name is what lets
pam_fprintd, the Plasma KCM and fprintd-enroll work unmodified.
Two honest limits. Authorisation is the conservative rule -- you may act on
your own prints, root on anyone's -- because polkit is not in this milestone.
And DeleteEnrolledFingers removes the finger's NAME only: FF_CMD_TA_REMOVE
exists but its payload is not reverse-engineered, and guessing at a command
that writes to the store is exactly how an index got invalidated earlier
today. A deleted finger loses its name and stops being offered; its template
still occupies a slot in the group. Logged as such.
The finger-name map is written per user under the state directory, tmp-file
and rename. An enrolment records the fid the trustlet reported in the touch
event's response; if none was reported the finger cannot be named yet, and
the daemon says so rather than inventing one.
Verified on the phone as a systemd unit: owns the bus name, init chain
complete, floor calibrated, ready.
fingerprintd's own code now talks to QTEE. On the phone:
root object on /dev/tee0
client env obtained (uid 0, 13-byte credentials)
QSEECOM-compat app loader (UID 122) opened
The credentials object is ours rather than libqcomtee's. Upstream's exists only
to build a thirteen-byte CBOR map and drags in QCBOR to do it, so
packaging/make-libqcomtee.sh compiles the two sources that matter and drops
credentials_obj.c entirely -- nothing else references it, and the library then
has no dependency beyond libc. The map is built in Fingerprintd:Tee where it is
pinned byte-for-byte against the string verified on-device, and the object's
two-op read protocol is served here.
Three interop details, all of which cost a build cycle:
* libqcomtee's headers carry no extern "C" guard, having only ever been
consumed from C, so everything came out C++-mangled. They also pull in
<stdatomic.h> and <stdio.h>, which under libc++ drag in templates that may
not appear inside extern "C" -- so those are included first.
* tee_call_t's second parameter is unsigned long on glibc and int on musl.
The native build is glibc and the phone is musl; both forms are compiled.
* On the callback path a UBUF_OUTPUT param arrives with addr = NULL. The
dispatcher supplies the buffer, so a handler POINTS the param at its own
storage rather than writing through the incoming address. Doing the latter
is a null dereference that takes the supplicant thread with it, which is
how the first run against real QTEE ended -- with the correct behaviour
already spelled out in the module comment above the code that ignored it.
That comment now says so in as many words.
packaging/make-sysroot.sh populates a minimal Alpine aarch64 rootfs with
apk-tools-static, so a cross build needs no root, no qemu and no phone. Adapted
from imsd's, plus glib-dev for the bus layer that is coming.
Building against a real Alpine sysroot means the binary links dynamically
against the phone's own musl and libc++ -- libc++, libc++abi, libunwind and
libgcc_s are all already on pmOS. The harness this daemon replaces had to be
built -static, but only because it was built with the host's glibc toolchain;
that constraint was never about the target.
The pipeline is proven end to end rather than assumed: the cross-built binary
runs on the phone, and all five core suites pass there too -- on the real
hardware, not just under qemu-aarch64. That matters for modules that are almost
entirely little-endian field packing and offset arithmetic.
