Reliability fixes and 1:N identification for the MAFP driver#5
Conversation
libfprint requires retry errors during verify to be reported through fpi_device_verify_report() and the operation completed without an error. Passing an FP_DEVICE_RETRY error directly to fpi_device_verify_complete() makes libfprint log "Driver reported a retry error ... not permissible" and turns a recoverable bad finger placement into a general verification failure.
Set temp_hot_seconds to -1 so libfprint does not apply its generic time-based overheating estimator to the USB Microarray MAFP reader. The device reports false TOO_HOT/overheating states while remaining cold and recoverable via USB reset.
fprintd could never stop a pending verify: no cancel support existed (transfers had NULL cancellables and no is-cancelled checks), so VerifyStop/Release during the lock screen's fingerprint wait hung inside the daemon, leaking the device claim. The next unlock attempt then failed with 'Device was already claimed' and fprintd had to be SIGKILLed and the reader USB-reset. Check fpi_device_action_is_cancelled() once per GET_IMAGE polling iteration in both enroll and verify, failing the SSM with G_IO_ERROR_CANCELLED. Checks happen only at packet boundaries; transfers keep NULL cancellables because aborting mid round-trip would leave an orphaned response queued on the bulk-IN endpoint and desynchronize the command/response stream. Also throttle the verify polling loop with the same 100ms timer enroll already uses (it previously re-polled with no delay, hammering the sensor continuously for the whole time the screen stayed locked), and unref the print's fpi-data variant leaked on every verify.
The chip has 30 template slots (0-29), but some ReadIndex responses expose a 32-bit bitmap. Selecting slot 30 or 31 makes the subsequent StoreChar fail with status 0x18, aborting the enrollment.
fprintd only performs multi-finger matching through the identify vfunc: on VerifyStart with finger 'any' and more than one enrolled print, a device without FP_DEVICE_FEATURE_IDENTIFY is verified against the first gallery print only, so every other enrolled finger can never match at the lock screen or sudo prompt. The chip has no native 1:N search command (CMD 0x66 matches the char buffer against a single FID), so identification captures one image and walks the gallery, re-running GenChar before each Search because a Search invalidates the char buffer; the image buffer persists, so no re-capture is needed. Cancellation is honoured at the same packet boundaries as verify. As a side effect, fprintd's duplicate-print detection at enrollment start now works (it requires identify), which adds one extra finger touch at the beginning of each enrollment.
After hours of an armed verify/identify (KDE lock screen left locked overnight) the sensor firmware keeps ACKing GetImage but stops actually capturing, leaving the reader deaf with no error anywhere. Verify and identify now handshake (CMD 0x23 session reset) at start like enroll always did, and re-send it after every 600 empty polls (~60 s), so the capture engine can never go stale by more than a minute. No refresh mid-enroll (would wipe accumulated char buffers) or post-capture in identify (would wipe the image buffer).
|
Warning Review limit reached
Next review available in: 48 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes for several failure modes that surfaced in daily use of this driver
with fprintd and the KDE Plasma lock screen (PAM
kde-fingerprint), where averify can stay armed for hours, plus 1:N identification support.
Fixed
verify/enroll: when the lock screen tore down its PAM conversation,
fprintd kept the device claim leaked ("Device was already claimed") until
the daemon was SIGKILLed and the reader USB-reset. Operations now honour
cancellation at packet boundaries (
fpi_device_action_is_cancelledchecksin the GetImage polling loops). USB transfers deliberately keep a NULL
cancellable: this is a strict command/response protocol, and cancelling a
transfer mid round-trip leaves an orphaned response on the bulk-IN
endpoint that desynchronizes every subsequent exchange.
continuous GetImage polling (screen locked overnight) the firmware keeps
ACKing GetImage but stops actually capturing, with no error anywhere.
Verify and identify now start with the handshake (CMD 0x23 session reset)
like enroll always did, and re-send it after every 600 empty polls (~60 s),
so the capture engine can never go stale by more than a minute. No refresh
mid-enroll (would wipe accumulated char buffers) or after capture in
identify (would wipe the image buffer).
of busy-polling the sensor over USB (56eaac7).
fpi_device_verify_report()(06c4e4f), aslibfprint requires; a bad finger placement stays recoverable instead of
failing the whole operation.
overheating estimator produced TOO_HOT lockouts on this always-on external
reader;
temp_hot_seconds = -1.Only 30 template slots exist; StoreChar
Added
one capture is matched against the whole gallery: Search (CMD 0x66) per
FID, re-running GenChar between attemptschar
buffer while the image buffer persists. Without identify, "any"-finger
verification only ever checked the firstables
fprintd's duplicate-print detection at enrollment.
Validation
G_MESSAGES_DEBUG=allon hardware(3274:8012): session refresh fires exactsumes;
a client SIGKILLed mid-verify is cancelled at the packet boundary and the
same daemon serves the next claim with n
exercised); the overnight-deafness fix i