Name the cause when libfprint cannot drive the fingerprint reader - #11047
Open
codeclawd wants to merge 1 commit into
Open
Name the cause when libfprint cannot drive the fingerprint reader#11047codeclawd wants to merge 1 commit into
codeclawd wants to merge 1 commit into
Conversation
omarchy-hw-fingerprint matches readers on vendor ID, and 06cb and 138a are both on its list. Three of those devices -- 06cb:009a, 138a:0090 and 138a:0097 -- have no libfprint driver at all; only the community's reverse-engineered python-validity daemon talks to them. So setup detects a reader, installs libfprint-git, and runs all the way to enrollment before fprintd reports "No devices available". That surfaces as the generic "Enrollment failed. Please try again.", which is indistinguishable from a bad swipe and sends people into a retry loop that cannot succeed. Check for those three IDs on enrollment failure and say what is actually wrong, pointing at python-validity. The device list is python-validity's own udev match set from 94-validity-sensors.rules. This only changes the failure message; nothing new is installed and the supported path is untouched. Verified on a ThinkPad T480 with 06cb:009a (Synaptics Metallica MIS Touch), where the reader does work once python-validity is driving it. The helper matches that device, and declines both an unrelated device and an empty device tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqYR76DqmNVGYtGYUpyJmv
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
omarchy-hw-fingerprintmatches readers on vendor ID, and06cband138aare both on its list. Three of those devices —06cb:009a,138a:0090and138a:0097— have no libfprint driver at all; only the community's reverse-engineered python-validity daemon talks to them.So
omarchy setup security fingerprintdetects a reader, installslibfprint-git, and runs all the way to enrollment before fprintd reportsNo devices available. That surfaces as:which is indistinguishable from a bad swipe, and sends people into a retry loop that cannot succeed. The script already anticipates this shape of failure — the comment above
setup_pam_confignotes that an Elan MOC sensor outside the elanmoc table "gets this far and then fails to enroll" — this just names the cause for the three devices where it's knowable up front.Change
On enrollment failure, check for those three IDs and say what's actually wrong:
Only the failure message changes. Nothing new is installed, the supported path is untouched, and the device list is python-validity's own udev match set from
94-validity-sensors.rulesrather than a guess.Verification
Tested on a ThinkPad T480 with
06cb:009a(Synaptics Metallica MIS Touch), where the reader does work once python-validity is driving it —fprintd-listgoes from "No devices available" to "found 1 devices", and enrollment andfprintd-verifythen succeed.The helper honours
OMARCHY_USB_DEVICES_PATH, so it is testable the same wayomarchy-hw-fingerprintis:1234:5678→ declines🤖 Generated with Claude Code
https://claude.ai/code/session_01CqYR76DqmNVGYtGYUpyJmv