How I got my HP fingerprint sensor working on Linux.

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:

1. The kernel already supports it (out of the box)
2. Someone reverse-engineered the protocol and shipped a userspace driver
3. The vendor ships a Linux driver (rare outside of mainstream chipsets)
4. 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

$ lsusb | grep -i validity
Bus 001 Device 019: ID 138a:00ab Validity Sensors, Inc.

Searching 138a:00ab led to linux-hardware.org's page, which confirmed the model ("Validity Sensors Synaptics VFS7552 Touch Fingerprint Sensor with PurePrint") and the bleak status: 649 reports, all failing.

The PurePrint suffix sounded ominous. Looking at the USB endpoint structure (5 endpoints: one bulk OUT, two bulk IN, two interrupt IN), I figured PurePrint probably added an encrypted channel on top of the plain VFS7552 protocol. Spoiler: I was half right.

The first dead end: the libfprint vfs7552 driver

libfprint ships a driver called vfs7552 for the Dell XPS variant of this chip (PID 0091). I cloned the repo, added 0x00ab to its PID table, rebuilt, and tried it:

cmd_01 (rom info) ............. OK, 38 bytes returned
cmd_19 ........................ OK, 68 bytes
vfs7552_init_00 (501 bytes) ... rejected, status 0x04be

The chip accepted the basic identification commands and returned valid-looking data. It just refused the 501-byte initialization blob that the Dell driver wanted to send.

Diffing the cmd_01 response against the Dell reference values, my chip and the Dell one agreed on the first 18 bytes (sensor family identifier) but differed in a few bytes that looked like firmware version (0x03d1 vs 0x0000) and a per-chip serial number. The init blob is firmware-version-specific. Sending the Dell's blob to my chip is like sending Windows XP install media to a Mac.

I tried disassembling the HP Windows driver (synaWudfBioUsb.dll, extracted from the official HP softpaq) in radare2 to find the right bytes to send. I got far enough to confirm the driver does ECDH key exchange and signed firmware upload — BCryptGenerateKeyPair, BCryptSecretAgreement, BCryptSignHash all in the imports — but the actual byte sequences turned out to be dynamic, not static. They're constructed from runtime crypto, not stored as constants you can grep for.

The libfprint path was over. The chip wasn't really a vfs7552; it was something more sophisticated wearing a vfs7552 marketing label.

The pivot: python-validity

python-validity is uunicorn's reverse-engineered userspace driver for the chips Synaptics calls "Prometheus" — 138a:0090, 0097, 009d, 06cb:009a. These chips do real TLS-like crypto handshakes and signed firmware upload, which matched what I'd seen in the disassembly.

The architecture made me hopeful: maybe 0x00ab was just a Prometheus chip wearing a vfs7552 marketing label. The protocol bits I'd already verified (cmd_01, cmd_19) are also what python-validity's usb.send_init() sends first.

I wrote a minimal test script that:

1. Opened the device
2. Sent cmd_01, cmd_19, cmd_4302 (basic info queries) — all worked
3. Sent python-validity's init_hardcoded blob (a 581-byte crypto blob for the supported chips)

init_hardcoded (581 bytes): send 06 02 00 00 01 4a 23 14 06 e5 54 2f c6 dc 3b 1a ...
recv 2 bytes, status=00 00: 00 00

0000. Status OK. The HP chip accepted python-validity's blob, which meant: same protocol family. Verified by going further and completing the full ECDH key exchange — the encrypted channel established cleanly against the chip's factory TLS state.

The painful middle: I thought I was stuck

I patched python-validity to support 00ab. The service started. fprintd-enroll ran, asked for finger swipes, completed. fprintd-verify... hung forever.

$ 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 greps 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.