I bought a used HP EliteBook 840 G5 last year. Cleaned it up, wiped Windows, put Ubuntu on it. Everything worked except the fingerprint reader, which I figured I'd get to "eventually." "Eventually" turned out to mean three sessions, several wrong turns, a USB reverse engineering side quest, and a one-line fix that fixes the same problem for a chunk of HP laptops nobody had been able to use on Linux. The expectation: just install a driver This is the thing non-Linux people (and a lot of Linux people, honestly) get wrong about hardware support. You don't "just install a driver." Either: The kernel already supports it (out of the box) Someone reverse-engineered the protocol and shipped a userspace driver The vendor ships a Linux driver (rare outside of mainstream chipsets) It doesn't work My sensor was case 4. Specifically: 138a:00ab , a Synaptics VFS7552 chip with their "PurePrint" anti-spoofing variant. Synaptics only ships a Windows driver. libfprint (the standard Linux fingerprint library) has no driver for this PID. python-validity (the heroic community reverse-engineering project) supports the related Lenovo Prometheus chips but not mine. Of 649 systems with this exact device logged on linux-hardware.org, zero worked on Linux. There were three open GitHub issues asking for support, the oldest from 2023. So that was the starting point. Step one: figure out what you actually have fprintd-verify Using device /net/reactivated/Fprint/Device/0 Listing enrolled fingers: - # 0: right-index-finger Verify started! Verifying: any ^C # me, after a minute of nothing I figured the problem was that python-validity's sensor.open() only knows two sensor type profiles ( 0x199 and 0xdb ), and my chip reports 0xd51 . With the wrong profile, image dimensions and calibration parameters would be wrong, producing garbage images. I spent hours on this hypothesis. Tried both profiles. Looked for ways to extract the right values from Windows. Read the open issues. Issue #225 — same 0xd51 sensor type on a different USB ID — was a user who had hit the exact same wall with the exact same patches I'd applied. They got stuck at the same place. The narrative I had in my head was: this is the calibration wall. Without per-chip data extracted from Windows, we're done. I started writing the apologetic "we did good work but here's where it ends" wrap-up. Looking at the actual data But before giving up I added one more piece of instrumentation: dump every TLS-decrypted response over 100 bytes to disk. Re-enrolled. Looked at what came out: 4104 B cmd40 (× 4) calibration frames 1966 B cmd02 (× 9) per-stage frame data 5040, 9584, 14128, 14128, 18672, 18672, 18672, 23304 B cmd6b enrollment template The enrollment template was growing by ~4500 bytes per scan. That's real feature data accumulating. If the chip were producing garbage images, the matcher wouldn't have anything to extract features from — the template wouldn't grow. I rendered the cmd02 frames as 44×44 grayscale PNGs. They didn't look like noise. They looked like fingerprint ridges. The chip was capturing real images. The matcher was building real templates. So why did verify hang? The actual bug I went back and stared at sensor.capture() : def capture ( self , mode ): assert_status ( tls . app ( self . build_cmd_02 ( mode ))) # start b = usb . wait_int () if b [ 0 ] != 0 : raise Exception ( ' wait_start: Unexpected interrupt type ... ' ) # wait for finger while True : b = usb . wait_int () if b [ 0 ] == 2 : break # wait capture complete while True : b = usb . wait_int () if b [ 0 ] != 3 : raise Exception ( ' Unexpected interrupt type ... ' ) if b [ 2 ] & 4 : break ... Three interrupt phases: start, finger-detected, capture-complete. I went back to the journal logs and looked at what interrupts my chip was actually sending: <int< 00 00 00 00 00 # b[0] = 0 (start) <int< 03 20 07 00 00 # b[0] = 3 (capture event) That's it. Two interrupts. The chip never sent b[0] = 2 "finger detected." It skipped straight from start to capture event. So the wait-for-finger loop sat there forever, waiting for an interrupt that was never coming. The chip had captured the image, the matcher had a result, but the daemon couldn't tell because of an infinite loop in user code. The fix: # wait for finger. Sensor type 0xd51 (138a:00ab, 06cb:00b7) does not
emit b[0]=2; it jumps directly to capture events. Accept b[0]=3 as
a substitute and save the interrupt for the next loop. saved_b = None while True : b = usb . wait_int () if b [ 0 ] == 2 : break if b [ 0 ] == 3 and getattr ( self , ' real_device_type ' , None ) == 0xd51 : saved_b = b break # wait capture complete while True : b = saved_b if saved_b is not None else usb . wait_int () saved_b = None ... Eight lines, gated on the chip type so existing supported chips take the unchanged code path. Restart the service. Re-enroll. fprintd-verify : Verify result: verify-retry-scan (not done)
Verify result: verify-retry-scan (not done) Verify result: verify-match (done) A correct finger matched. Tried with a different finger: Verify result: verify-no-match (done) Real matching, real rejection. Wired it through PAM: $ sudo -k && sudo whoami [sudo] Place your finger on the fingerprint reader root What was actually hard about this The thing that fooled me, and fooled everyone else who had tried was that the chip appeared to be calibration-stuck. Enrollment completed (because enrollment uses a slightly different code path that doesn't wait for b[0]=2 ). Verify hung. The natural conclusion was "matching fails, images are bad." Everyone tried fiddling with the sensor profile. Nobody tried instrumenting the interrupt stream. Looking at the actual returned data was the move. The cmd6b templates growing by 4500 bytes per scan was the smoking gun: the chip was clearly producing real features, which meant the chip was capturing real images, which meant the image pipeline was working, which meant the problem had to be after image capture and before match results came back. That's a small window and the wait-finger loop was sitting in it. What's in the patch The PR is at uunicorn/python-validity#256 . +37 / -3 lines across five files. It: Wires 138a:00ab and 06cb:00b7 through the SupportedDevices enum, blob routing, firmware mapping, and udev rules Aliases sensor type 0xd51 to the 0x199 profile so downstream SensorTypeInfo / SensorCaptureProg lookups succeed (no native profile exists yet — empirically 0x199 is close enough that the on-chip matcher accepts real images) Patches Sensor.capture() to accept b[0]=3 as a substitute for b[0]=2 , gated on the real device type If it merges, three open issues get closed: #181 — open since 2023 #225 — 06cb:00b7 user with the same wall #238 — newer report If you have one of these chips and don't want to wait for the merge, you can clone my fork branch: git clone -b feat/sensor-type-0xd51 https://github.com/SimpleX-T/python-validity.git sudo pip install --break-system-packages --prefix = /usr ./python-validity sudo systemctl restart python3-validity.service (You'll also need open-fprintd and the supporting D-Bus / systemd / udev plumbing, which the PR description and python-validity's debian/ folder document.) Takeaways Hardware support on Linux is not "downloading a driver." When the vendor doesn't ship one, real people spend real weeks reverse-engineering protocols. Look at the python-validity codebase sometime; the existing supported chips have ~500-byte chip-specific crypto blobs in them that were extracted from USB captures of Windows driver sessions. That work doesn't happen by itself. When a hypothesis explains some of the evidence, don't stop. I had a clean story — "calibration is wrong, images are bad, matching fails" — that explained the verify failure. It did not explain why enrollment completed cleanly and why the template was growing. I should have noticed the contradiction earlier. Look at the actual data the chip is sending. Adding the TLS-response dump took ten minutes and changed everything. I had been reasoning about what I thought the chip was sending; the actual bytes told a different story. AI-assisted reverse engineering is a real workflow now. I did this with Claude Code; the model held the protocol knowledge I didn't have and ran disassemblers and code searches in parallel while I was deciding what to do next. The interrupt-handling insight was a result of "let me actually look at every byte the chip sent us and check the contradictions" — a kind of careful empiricism that's much easier with an assistant doing the bookkeeping. If you've got a Validity/Synaptics fingerprint reader that doesn't work on Linux, check the USB ID and the open python-validity issues before assuming it's hopeless. There's a lot of "almost working" out there. Credits I didn't do this alone. All three sessions of this — the libfprint dead end, the python-validity pivot, the calibration rabbit hole, and finally the interrupt-loop fix — happened in Claude Code , with Claude Opus as a pair. The model held protocol details I didn't have, ran disassemblers and grep s and test scripts in parallel while I was deciding what to do next, and kept track of every hypothesis we'd already ruled out. The interrupt-handling insight came out of "wait, the template is growing — that contradicts the bad-images story; what else could it be?" which is a kind of careful re-examination that's much easier when you've got a partner doing the bookkeeping. The hardware was mine. The patience for re-enrolling a finger thirty times was mine. The decisions about when to give up and when to push were mine. But the protocol memory and the second pair of eyes were Claude's, and I want to call that out because "I built X" stories tend to hide the assist.