Can You add Support to 138a:00ab Validity Sensors, Inc.

[Killersparrow1]

HP HP EliteBook 840 G5

[SimpleX-T]

Hey @Killersparrow1 — 138a:00ab on the EliteBook 840 G5 is now supported:

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

Builds for Ubuntu 22.04, 24.04, 25.10, and 26.04. After install, enroll via Settings → Users → Fingerprint Login, or sudo fprintd-enroll -f right-index-finger $USER.

[Killersparrow1]

Super Great work sir tested on Fedora 44 working.

[SimpleX-T]

I'm glad it worked for you.

[Killersparrow1]

Hi small issue, on every reboot and poweroff the thing get vanished, I've to manually enter
this From Gemini

# 1. Stop the services to release the busy USB lock
sudo systemctl stop python3-validity open-fprintd

# 2. Tell the kernel to reset the specific USB port your sensor is plugged into
sudo udevadm trigger --attr-match=idVendor=138a --attr-match=idProduct=00ab

# 3. Start the services back up so they can freshly initialize the chip
sudo systemctl start python3-validity open-fprintd

then only the OS detect the fp and on restart or power off it'll get vanish need to run this again.

any fixes sir.

[SimpleX-T]

Hey @Killersparrow1 — really glad it works on Fedora 44, thanks for confirming it crosses distros.

The reboot issue is fixed in commit cd0def0 on the branch. The fix is a defensive USB reset at the start of Usb.open_dev() — same effect as your manual udevadm trigger workaround, but built into the driver so it runs automatically every time the daemon opens the chip. No more "vanishes on reboot."

To update on Fedora, rebuild from the latest branch tip:

• If you used git clone + setup.py install, do git pull in the working tree then re-run install.
• If you used pip install git+https://github.com/SimpleX-T/python-validity.git@feat/sensor-type-0xd51, just rerun that command.

Then sudo systemctl restart python3-validity.service and it should survive reboots cleanly. Let me know if anything else comes up!

[ggiesen]

Heads-up for other 138a:00ab owners: that USB ID covers at least two different sensor silicon. @SimpleX-T's branch handles the HP EliteBook 840 G5 variant, which reports sensor type 0xd51. The HP ZBook Studio x360 G5 uses the same 138a:00ab PID but a different chip reporting sensor type 0x969 (identifies as "57K0 ..."), so the 0xd51 aliasing doesn't pick it up.

It's a 57K0-family part, so it aliases cleanly to the same 0x199 profile. Three-line mirror of the existing 0xd51 handling:

• add 0x969 to line_update_type1_devices
• alias 0x969 -> 0x199 in Sensor.open()
• accept the b[0]==3 finger interrupt when real_device_type is 0x969

Verified end-to-end on an HP ZBook Studio x360 G5: init + calibration + enroll (5 stages, enroll-completed) + verify (verify-match), and Mint's fingwit GUI drives it via open-fprintd. PR against @SimpleX-T's branch: SimpleX-T#2

[SimpleX-T]

Quick update for this thread since a lot converged here:

@ggiesen — thanks for filing SimpleX-T/python-validity#2. Merged into the PR branch (0c00f0a); the 0x969 handling for HP ZBook Studio x360 G5 is now upstream in PR #256 along with your test evidence.

@Killersparrow1 — your "vanishes on reboot" issue has been fixed on the branch since cd0def0 (defensive USB reset in open_dev()), which is in the current PPA build. On any of your machines that still need the manual udevadm trigger workaround, updating from the PPA should resolve it.

PR #256 just got four more commits covering post-resume recovery for 0x969, friendlier errors when the reset_blob is rejected on this chip family (0xd51 / 0x969 don't accept the reset_blob we ship — no fix yet, but a real error message + tracking pointer), and Karloss1234's flash-management diagnosis. Details on PR #256.

Next: rolling all of this into PPA build 0.16~hp8 for jammy/noble/questing/resolute.