Reading the Ridges — blog.spandang.com

My Dell XPS 13 9370 has a fingerprint reader built into the power button. I run Omarchy (Arch + Hyprland) on it, and as far as the OS was concerned, that sensor didn’t exist — no entry in fprintd, no option on the lock screen, nothing. I’d more or less accepted I’d be typing my password forever.

I finally sat down with Claude Code to chase it down properly, and it turned into a better debugging session than I expected — not because the fix was hard, but because it kept surfacing the right next question instead of just throwing commands at the problem. Here’s how it actually went, warts included.

Step 1: find out what’s actually plugged in

Before touching any config, Claude ran the basics:

$ lsusb | grep -iE "valid|synap|goodix|finger|138a|06cb"
Bus 001 Device 004: ID 27c6:5385 Shenzhen Goodix Technology Co.,Ltd. Fingerprint Reader

$ fprintd-list $(whoami)
No devices available

The hardware was there. fprintd and libfprint were already installed — Omarchy ships them by default, and the daemon was running. But the driver refused to see the device. Hardware present, driver silent — that gap is exactly the kind of thing worth reading source and data files for, instead of guessing. Claude pulled the compiled driver strings out of libfprint-2.so.2 and grepped the udev hardware database directly:

$ grep -rn "27c6\|5385" /usr/lib/udev/hwdb.d/*.hwdb
60-autosuspend-libfprint-2.hwdb:494:usb:v27C6p5385*

Finding. Right there in 60-autosuspend-libfprint-2.hwdb, under a section literally labeled # Known unsupported devices. My exact sensor was explicitly denylisted by upstream libfprint — this was never an Omarchy config problem. The goodixmoc driver only supports Goodix’s newer match-on-chip sensors; mine is an older generation needing a completely different driver.

Step 2: find the fix someone else already built

This is usually where people resign themselves to typing passwords forever, so Claude went looking for prior art instead — searching the exact USB ID plus “linux driver” and “reverse engineering,” then checking GitHub and the AUR directly rather than trusting search snippets.

It found AndyHazz/goodix53x5-libfprint, packaged for Arch as libfprint-goodix53x5. Rather than take the README’s word for it, it queried the AUR RPC API directly:

$ curl -s "https://aur.archlinux.org/rpc/v5/info/libfprint-goodix53x5"
maintainer: AndyHazz · updated 3 weeks ago
targets: 27c6:5335, 27c6:5385, 27c6:5395

Maintained by the same person as the upstream driver, recently updated, targeting my exact chip. Since this sensor has no real match-on-chip silicon, the driver works by grabbing a raw 108×88px image off the USB endpoint and matching it in software via OpenCV. Not what I expected to learn about my laptop’s power button, but good to know.

Step 3: the install saga

A Goodix sensor with a real community driver should be a one-line yay -S away. Almost. Three separate speed bumps showed up, each with its own actual cause rather than a workaround:

Conflict with the stock package. Omarchy ships libfprint-git by default, which conflicts with libfprint-goodix53x5. Expected — yay handles it with a confirmation prompt.

Non-interactive sudo. The build needs sudo to install make dependencies (meson, ninja, gtk-doc), and there was no way to feed a password from a non-interactive shell. The fix was simple: run it myself, interactively, so the password prompt actually reaches a terminal.

A genuinely obscure build error:

libfprint/meson.build:185:17: ERROR: Dependency 'glib-2.0' tool variable
'glib_mkenums' contains erroneous value: '/usr/bin/glib-mkenums'

Instead of guessing, Claude checked whether the file actually existed — it didn’t, and no package owned it. Arch had recently split glib2 into a runtime package and a separate glib2-devel package holding the dev tools. pkg-config still pointed at the old path; the file behind it was simply gone. sudo pacman -S glib2-devel, retry, done.

Step 4: enrolled, but it wouldn’t verify

With the driver installed, fprintd-list finally showed the Goodix HTK32 Fingerprint Sensor. Enrollment succeeded first try. But fprintd-verify came back verify-no-match every time.

Worth ruling out the boring explanation before assuming the driver was broken: a verify command run with nobody physically present to touch the sensor at the right moment will always time out — that’s a different failure than a genuine mismatch. Once I ran it myself and touched the sensor on cue, it really was a bad match, not a fluke. The fix was blunt — delete the sloppy enrollment and redo it carefully, same firm, flat, centered placement each of the eight presses. Verification matched cleanly on the second try.

Step 5: PAM, and a terminal line-wrap gremlin

Sudo and polkit already had pam_fprintd.so wired in by Omarchy — it just needed a working driver underneath. The lock screen (hyprlock) didn’t have it, so that needed adding by hand. The one-liner to do it looked reasonable, but produced:

sed: -e expression #1, char 80: unterminated 's' command

Root cause. My terminal had visually wrapped the long sed command, and copy-pasting turned that wrap into two real lines. GNU sed’s i text form only grabs the rest of that physical line — so the second line got parsed as its own command, and sufficient (starting with s) looked like a botched s/// substitution. Nothing on disk had actually changed; sed aborted cleanly. The fix was to stop fighting one-liners and edit the file directly in nano instead.

Later I tried Omarchy’s built-in fingerprint option from its settings menu and got a package conflict error mid-setup. Rather than assume something had broken, the actual scripts got read straight off disk: omarchy-setup-security-fingerprint defaults to installing Omarchy’s own libfprint-git fork — the exact package already proven not to support this sensor at all. Pacman refused the conflicting transaction and rolled back cleanly; nothing was actually damaged. Lesson learned: leave that menu option alone from here on, and make driver or PAM changes by hand.

Step 7: one last mystery — new fingers wouldn’t unlock

I enrolled a couple more fingers for convenience, but they didn’t seem to work at the lock screen. Rather than guess whether this was an enrollment problem or a hyprlock problem, Claude read hyprlock’s actual source, which showed it calls fprintd’s VerifyStart with "any" as the finger argument — meaning every enrolled print should already work there. That pointed the debugging back at enrollment quality rather than hyprlock’s config, and testing each new finger at the CLI (the same “any finger” match hyprlock uses) confirmed they were fine all along.

Where it landed

Sensor detected, community driver in place of the unsupported stock one, three fingers enrolled and verifying, PAM wired into sudo, polkit, and the lock screen. A short but real list of gotchas along the way: a device explicitly denylisted upstream, an Arch package split that broke a meson build, a terminal line-wrap that made a working sed command misbehave, and a first-party setup script that would have silently reintroduced the exact broken driver I’d just replaced.

None of these were individually hard once identified. What made the session fast was refusing to guess at any of them — checking the actual hwdb entry instead of assuming “unsupported,” querying the AUR API instead of trusting a README, checking whether a file really existed instead of assuming the build tool was lying, and reading hyprlock’s actual source instead of assuming its config was wrong. Every step had a command that could confirm or kill the working theory, and running it was always faster than debating it.