DEV Community: Mark Ndubuisi

How I got my HP fingerprint sensor working on Linux.

Mark Ndubuisi — Wed, 20 May 2026 05:40:55 +0000

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.

TL;DR — if you just want it to work

If you've got a Validity/Synaptics sensor with USB ID 138a:00ab or 06cb:00b7 (HP EliteBook 840 G5 and several HP G6-family laptops), you don't need to read the rest. Run:

sudo add-apt-repository ppa:devtochukwu/fingerprint
sudo apt install python3-validity

Builds for Ubuntu 22.04 (jammy), 24.04 (noble), 25.10 (questing), and 26.04 (resolute). Enroll a finger via Settings → Users → Fingerprint Login, or sudo fprintd-enroll -f right-index-finger $USER from the terminal. sudo, screen unlock, and GNOME login are all wired up automatically.

The rest of this post is why this took multiple sessions and a USB reverse-engineering detour to fix.

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

$ 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:

Opened the device
Sent cmd_01, cmd_19, cmd_4302 (basic info queries) — all worked
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.

Unison: Building a Workspace Where Language Barriers Don't Exist

Mark Ndubuisi — Sun, 22 Feb 2026 08:49:13 +0000

The Problem Nobody Talks About

Remote work won. The debate is over. But here's the thing nobody seems to be solving well: your team is global now, but your tools still assume everyone speaks the same language.

Think about it. You've got a product manager in Tokyo writing specs in Japanese. A designer in Berlin annotating wireframes in German. A developer in Lagos writing task descriptions in English. They're all using the same Notion workspace, the same Slack channels, the same Google Docs — and they're all quietly struggling.

The usual workflow looks something like this: write something in your language, copy it, open Google Translate in another tab, paste, copy the result, paste it back into the shared doc. Multiply that by every message, every document, every comment, every day. It's exhausting, and it introduces a subtle but real friction that slows teams down and makes people feel like outsiders in their own workspace.

I had to work with some Japanese developers once, and I experienced this friction first-hand; I believe they did too. I had to manually translate messages sent to me before understanding what was sent, then I had to send back a manually-translated text, which was tiring and inefficient in a fast-paced modern workspace as the one we're in.

What We Built

Unison is a collaborative workspace where every piece of text — documents, chat messages, task descriptions, comments, UI labels — adapts to the reader's preferred language automatically. You write in yours. Your teammate reads in theirs. Nobody has to think about translation.

But Unison isn't just a "Google Docs with auto-translate bolted on." The core insight that drives the whole architecture is this: real-time collaboration and translation are fundamentally at odds, and you need a different model to make them work together.

The Features

Here's what Unison includes as a full workspace:

Collaborative Documents — A rich text editor with real-time sync, powered by Yjs CRDTs and TipTap
Chat Channels — Real-time messaging where every message is translated on-the-fly
Kanban Boards — Task management with drag-and-drop, priorities, and due dates
Whiteboards — An infinite canvas (powered by Tldraw) for visual collaboration
Git-Inspired Document Branching — The piece I'm most proud of, and the one that required the most thinking

All of it, in 12 languages. All of it, translated in real-time.

The Hard Problem: Why "Just Translate Everything" Doesn't Work

Early on, I tried the obvious approach: everyone edits the same document simultaneously (standard CRDT behavior), and we just translate the content for each viewer.

It broke immediately.

When two people type into the same paragraph at the same time — one in English, one in Japanese — the CRDT merges their keystrokes character by character. You end up with gibberish: half-English, half-Japanese fragments that can't be translated because they're not valid text in either language.

The core tension is: CRDTs are designed to merge concurrent edits at the character level. Translation operates on complete sentences and paragraphs. These two models are incompatible when applied to the same shared state.

The Solution: Git-Inspired Branching

The answer came from an unlikely place: Git.

In Git, you don't have everyone pushing to main simultaneously. You branch, you work, you submit a pull request, someone reviews, and then your changes get merged. We applied the same model to document collaboration:

The document owner works on main — they edit the canonical version directly
Collaborators get personal branches — when you open a shared document, Unison automatically creates your own branch (a fork of main). You edit freely in your own language, on your own Y.Doc instance
Submit for review — when you're done, you submit your branch. The owner sees it in their Merge Panel
Translate and merge — Unison translates the branch content into the document's original language, the owner reviews the translated preview, and merges it into main

Each branch gets its own Yjs document, its own Supabase Realtime channel (yjs:{docId}:branch:{branchId}), and its own persistence. Branches are fully isolated — no character-level conflicts across languages.

Owner (English)     ──── edits main Y.Doc ────────────────> main
                                                              ↑
Collaborator A (Japanese) ──── edits branch A ── submit ──── merge (translate JP → EN)
                                                              ↑
Collaborator B (Spanish)  ──── edits branch B ── submit ──── merge (translate ES → EN)

This was the "aha" moment. By separating the editing contexts and deferring the merge to a deliberate review step, we avoid the CRDT-vs-translation conflict entirely. Each person edits a clean, single-language document. Translation only happens once, at merge time, on complete content.

The Translation Architecture

Translation is the backbone of Unison, so getting it right was critical. We built a two-tier system:

Tier 1: Static UI Strings (Zero API Calls)

Every button, label, tooltip, and placeholder in the app is pre-translated into all 12 supported languages and bundled at build time. A useUITranslation() hook reads the user's preferred language from the Zustand store and returns the right string instantly — no network request, no loading state.

const { t } = useUITranslation();
// t("sidebar.documents") → "Documents" | "ドキュメント" | "Documentos" | ...

This covers 100+ UI string keys across every component. When you switch your language, the entire interface updates instantly.

Tier 2: Dynamic Content Translation (Three-Layer Cache)

For user-generated content — document text, chat messages, task titles, comments — we use a useTranslation() hook backed by a three-layer cache:

L1: In-memory Map — instant for repeated translations within a session
L2: Supabase translation_cache table — persists across sessions, shared across users
L3: Translation API — calls Lingo.dev SDK

The result: the first time someone's Japanese message gets translated to English, it hits the API. Every subsequent view — by any user, in any session — is a cache hit. Translation costs amortize to near-zero over time.

Lingo.dev as the Translation Engine

We use Lingo.dev as our primary translation engine via their SDK. It handles the actual text localization:

const engine = new LingoDotDevEngine({ apiKey: process.env.LINGODOTDEV_API_KEY });
const result = await engine.localizeText(text, {
  sourceLocale: fromLanguage,
  targetLocale: toLanguage,
});

Real-Time Chat Translation

The chat system is where translation feels most magical. Here's the flow:

A user in Tokyo types a message in Japanese and hits Enter
The message is stored in Supabase with original_language: "ja"
Supabase Realtime broadcasts the INSERT to all channel subscribers
Each recipient's client receives the message and passes it through useTranslation()
A user in Berlin sees the message in German. A user in Lagos sees it in English.

The sender sees their original message. The "Translated from Japanese" badge is subtle — just enough context to know it's a translation, not enough to break the flow of conversation.

The Tech Stack

Layer	Technology	Why
Framework	Next.js 16 (App Router)	Server components for initial data loading, client components for interactivity
Database + Auth + Realtime	Supabase	PostgreSQL with RLS for security, Realtime for live updates, Auth for identity — one service for three concerns
Real-Time Collaboration	Yjs + TipTap	Yjs CRDTs handle conflict-free editing; TipTap gives us a rich text editor on top
Translation	Lingo.dev SDK + DeepL (fallback)	Reliable, high-quality translations with redundancy
Whiteboard	Tldraw	Mature infinite-canvas library, stores state as serializable snapshots
State Management	Zustand	Lightweight, no boilerplate, perfect for user/workspace context
Drag & Drop	@hello-pangea/dnd	Accessible, performant drag-and-drop for the Kanban board
Styling	Custom CSS + CSS variables	Theming (dark/light mode), animations, no utility-class bloat in the markup

Architecture Decisions I'd Make Again

Branch-per-user instead of shared editing for cross-language docs. This was the biggest departure from "how collaboration tools usually work" and it paid off. The tradeoff is that collaborators can't see each other's edits in real-time — but that's actually fine when they're writing in different languages. You wouldn't be able to read their edits anyway.

Pre-translated UI strings instead of runtime translation. Translating 100+ UI strings at runtime would mean either (a) 100+ API calls on page load or (b) a loading spinner while UI text loads. Neither is acceptable. Pre-translating everything into a static dictionary and bundling it means the UI is always instant, regardless of language.

Three-layer translation cache. The in-memory cache makes repeated renders free. The database cache means translations survive page refreshes and are shared across users. The API is only called for genuinely new content.

Supabase for everything. Using one service for auth, database, and realtime means fewer integration points, fewer credentials, fewer things to debug at 2am during a hackathon. The RLS policies also mean our security model is enforced at the database level, not just in application code.

What I Learned

Building multilingual applications is a complex task, I never realized it until I started.
The modern workspace needs more tools like Unison, and we need to build them.
Building the collaborative document editor was probably the hardest of all, because I had to make it seamless and friction-less for collaborators.
If I had to start over, I will go with the diffing approach first, and then iterate from their; I believe I will have a better result that way.

What's Next

With guidance from the lingo.dev team, I plan to improve the translation mode from whole-text translation to per-word translation with backwards translation feature.
I plan to improve on the diffing mechanism to allow a smoother flow for collaborators on documents.
I will also improve the document editor tools, for more rich text editing.
I plan to integrate voice translation too (optimistic feature), so that teams can send voice notes across to each other, and also use the speech-to-text feature in editing documents.

Unison was built for the lingo.dev hackathon. The idea is simple: your tools should adapt to you, not the other way around. Language is context, not a barrier.

GitHub repo
Live demo

devtochukwu is product-oriented software engineer, with years of experience building real-world solutions on different platforms. Find him on X and LinkedIn.