linux-fingerprint-drivers

A community hub for driver code, patches, and setup notes for fingerprint sensors that are not yet supported in upstream libfprint.

If your sensor shows up in lsusb but fprintd-enroll fails or the device is unknown to libfprint, there may be a working fix here, or you can contribute one.

Browsable as a website, one page per sensor: https://fprint.jedbillyb.com

Check upstream first: if your reader is on libfprint's own supported devices list, use your distro's libfprint. This repo is only for the ones that are not.

• Find your laptop by model - start here if you do not know your USB ID
• Find your device
• Working fixes
• In progress (unmerged upstream MRs)
• Recently merged upstream
• Stale (MR closed without merging)
• Experimental community forks
• Vendor blob and non-LGPL routes
• Claimed upstream, but unreliable
• No known fix yet
• Building: docs/BUILD.md - build, install, PAM, troubleshooting
• Contributing

Find your device

Know your laptop but not your sensor? Look your machine up in docs/laptops.md, an index of every laptop model named anywhere in this repo or on the libfprint wiki, mapped to its USB ID and the route that works. Adding your own model there is the most useful small contribution you can make.

Otherwise, clone the repo and let the helper script match your hardware against everything catalogued here:

git clone https://github.com/jedbillyb/linux-fingerprint-drivers.git
cd linux-fingerprint-drivers
./tools/detect.sh              # or: ./tools/detect.sh 27c6:55b4

It scans lsusb for likely readers and tells you, per device, whether there is an entry here, whether it is on the known-unsupported list, or whether it is unknown to this repo entirely.

Doing it by hand: run lsusb and find the reader:

$ lsusb
...
Bus 003 Device 002: ID 27c6:55b4 Shenzhen Goodix Technology Co.,Ltd. FingerPrint
...

The 27c6:55b4 part is the USB ID (vendor:product), and it is the key this repo is organised by: see devices/27c6:55b4/. If nothing is obviously a reader, compare against the known sensor vendors: Goodix 27c6, Synaptics/Validity 06cb and 138a, ELAN 04f3, FocalTech 2808, FPC 10a5, Broadcom 0a5c, EgisTec 1c7a. Many newer sensors are on SPI or I2C and never appear in lsusb at all.

Working fixes

Status legend: Working (enroll + verify reliable), Partial (works with caveats), WIP (in progress). Statuses only move when someone reports back, so please open a device report with your distro and hardware either way.

Every entry needs libfprint built from source. The build, install, PAM, package pinning, troubleshooting and revert steps are the same for all of them and live in docs/BUILD.md; each device entry covers only what is specific to that sensor.

Note: 06cb:009a (Synaptics Prometheus) is handled by python-validity, a userspace driver daemon that plugs into fprintd via open-fprintd, rather than a libfprint driver. See its entry for the different stack.

Vendor blob and non-LGPL routes (catalogued, never hosted)

Some very common sensors have no open driver at all: the only thing that works is a proprietary vendor driver loaded through libfprint's TOD (Touch OEM Driver) mechanism, or a project under a license this hub cannot host.

This repo hosts only LGPL-2.1 code. But leaving these devices uncatalogued just means their owners find nothing and conclude Linux cannot use their reader, so they get entries that point at the vendor route and state the trade-offs plainly. Nothing proprietary is mirrored here, and a pointer is not an endorsement: read the caveats in each entry before putting a closed binary in your authentication path.

Still genuinely out of scope: sensors where nobody has published any working route at all (those live in the gap-map), and routes we cannot verify (see Contributing on the vetting bar).

In progress (unmerged upstream MRs)

Drivers that have been submitted to the official libfprint project but are not merged yet, so they are not in any released libfprint. Each has an entry under devices/ with the merge-request link and build notes. Status changes to Working here once someone confirms it, and the row moves once the MR lands upstream.

MR states were last verified against GitLab on 2026-07-26; the merge request itself is always the authority.

Recently merged upstream

These were WIP here but their merge requests have since merged into libfprint git master (2026-06/07). They will be in the next libfprint release; build from git to get them now. Entries are kept for people still on an older libfprint.

Stale (merge request closed without merging)

Entries kept as leads for anyone wanting to pick the reverse-engineering back up.

Experimental community forks (not upstream)

Drivers from community forks rather than upstream merge requests. These are not in libfprint and may be unstable; see each device entry for details.

Claimed upstream, but unreliable

libfprint listing your sensor as supported does not always mean it works. These have in-tree drivers that fail in practice, with open MRs that fix them. If your reader is detected but you cannot finish an enrollment, start here.

No known fix yet

115 more USB sensors are on the libfprint wiki's unsupported list with no working driver here or upstream. They are catalogued, with any known reverse-engineering leads, in docs/unsupported-devices.md - the contributor gap-map. If you own one of those, a protocol dump or a driver is very welcome.

SPI/I2C sensors (ELAN7001/7002/079C, GXFP5187/51B7, GDIX51C0, fpc1020, ...) are also largely unsupported and never appear in lsusb; see the wiki's SPI Devices section.

Contributing

New device entries, status reports, and corrections are all welcome. See CONTRIBUTING.md for the folder layout, required files, attribution, and license rules, and run python3 tools/check-repo.py before opening a PR.

Two things are worth as much as a driver: a report that an entry works (or stopped working) on your distro, and a protocol dump for anything in the gap-map.

Hosting vs cataloguing. Code and patches in this repo are LGPL-2.1 only. Cataloguing is broader: a device entry may point at a proprietary TOD blob or a differently-licensed project when that is the only thing that works, as long as the entry says so plainly and mirrors none of it.

Vetting bar. There are many small per-device fingerprint repos on GitHub, and a fair number are abandoned, unlicensed, or generated. An entry gets added when the route can be checked: real driver code, a license, and some evidence it worked on hardware. Unverifiable leads belong in an issue, not in devices/.

Where a fix belongs upstream, please also push it there: this hub exists to make unmerged work findable, not to replace libfprint. Entries whose merge requests land upstream get moved to the merged table and eventually dropped.

License

All driver code and patches hosted here are derived from libfprint and are licensed under LGPL-2.1. See LICENSE. Contributed code must be LGPL-2.1-compatible.

Device entries may link to routes under other licenses, including proprietary vendor drivers, where that is the only thing that works for a sensor. Those entries say so explicitly and mirror no code. See Vendor blob and non-LGPL routes.