Skip to content

Name the cause when libfprint cannot drive the fingerprint reader - #11047

Open
codeclawd wants to merge 1 commit into
omacom:quattrofrom
codeclawd:fingerprint-validity-hint
Open

Name the cause when libfprint cannot drive the fingerprint reader#11047
codeclawd wants to merge 1 commit into
omacom:quattrofrom
codeclawd:fingerprint-validity-hint

Conversation

@codeclawd

Copy link
Copy Markdown

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 omarchy setup security fingerprint detects a reader, installs libfprint-git, and runs all the way to enrollment before fprintd reports No devices available. That surfaces as:

Enrollment failed. Please try again.

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_config notes 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:

Enrollment failed: libfprint has no driver for this reader.
It is a Synaptics/Validity sensor that only the community
python-validity driver can talk to, so retrying will not help:
  https://github.com/uunicorn/python-validity

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.rules rather 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-list goes from "No devices available" to "found 1 devices", and enrollment and fprintd-verify then succeed.

The helper honours OMARCHY_USB_DEVICES_PATH, so it is testable the same way omarchy-hw-fingerprint is:

  • real sysfs on that machine → matches
  • device tree containing only an unrelated 1234:5678 → declines
  • empty device tree → declines

🤖 Generated with Claude Code

https://claude.ai/code/session_01CqYR76DqmNVGYtGYUpyJmv

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant