support for 06cb:00a2 (enroll on host, match on chip)

[dmitriy-myz]

With claude code resurrected my old work on support for this device.

✔️ it successfully add finger to sensor database directly on linux.
✔️ recognize finger
✔️ reset flow works

Need help to test this for already working sensors (full MoC flow)

closes #253 closes #185 closes #170 closes #139

if anyone interested, documentation in my fork https://github.com/dmitriy-myz/python-validity/tree/moh-opencv-poc/docs/transformation-doc

[Burghalim72]

Works but not user-friendly. For some reason had to factory reset it on Windows, as the script shipped with python-validity returned various errors by itself, and dbus_service also was returning errors. After resetting, enrolling sometimes works, and sometimes spams enroll-stage-passed and eventually enroll-failed. I don't know if I am doing something wrong.

Later I identified enroll-retry-scan every six presses. No idea why six when on Windows it reports such problems immediately.

After around 20 minutes of trying, I was only able to enroll one finger.

[dmitriy-myz]

@Burghalim72 have you tried to specify finger for enrollment? for me it failed because it trying to override same finger e.g.
fprintd-enroll -f right-thumb
fprintd-enroll -f right-index-finger
About reset command: this is true, reset blob most likely not correct

[Burghalim72]

I identified that enrolling breaks after enrolling one finger, until dbus_service is restarted. So with such hackfix is it possible to enroll all fingers by restarting it ten times, but it is obviously unacceptable on multi-user systems.

[Burghalim72]

Deleting enrolled fingerprints does not work either. It is "permission denied" as regular user and "unknown method" as root. Factory reset remains broken and bricks the sensor until properly reset on Windows (though fingers enrolled on Linux remain enrolled).

[dmitriy-myz]

enrolling breaks after enrolling one finger

fixed, thank you!

[Burghalim72]

It actually turned out it is possible to delete fingers, but only all of them per user. There is no individual finger deleting option on Windows either, no idea if it is a bug, or the device itself lack the feature.

As for "bricking", I was wrong. I redirected the device to another VM that lacks the driver and didn't even finish booting, and then cancelled the redirection immediately. Then python-validity started working again. I guess what actually happened is that device breaks until it is reconnected.

Factory reset works to an extent with old blob from a few years ago. However, in such case the device actually cannot be used until it is connected to a Windows VM with a proper driver. But once done, factory reset is actually performed and there are no fingers.

[Burghalim72]

Factory reset still requires booting into Windows to complete it. Maybe there are some other incorrect blobs.

I noticed CPU usage is higher when enrolling fingerprints via this program. When I enroll fingerprints, CPU fan starts spinning, which does not happen in Windows VM.

Enrolling itself seems to be different from Windows Hello as well. The latter not only asks to put a finger on the sensor six times, but sometimes also to put it three more times with different angles. python-validity never asks for this, at least if I understand it correctly.

Error "Exception: Unexpected TLS version 4 0" sometimes appears when running fprintd-verify (enroll just fails with enroll-failed immediately). I didn't manage to identify when it happens yet. Another random error identified later is dbus_service crashing with "[Errno 19] No such device (it may have been disconnected)".

Enrolling fingerprints on Windows Hello (Windows SID is not linked with Linux username via config at the moment) seems to cause individual fingerprints enrolled on Linux to disappear (so maybe individual fingerprints removal can be implemented?), but it doesn't seem to be caused by lack of space on the chip, as fingerprints can be readded on Linux, without affecting Windows ones. I don't know if it has anything to do with python-validity.

[Burghalim72]

With "fix reset flow" commit, reset can now be performed in a loop, but dbus_service doesn't work after it without booting into Windows VM. First time it just stops with no message, second time it is "FileNotFoundError: [Errno 2] No such file or directory: '/var/run/python-validity//6_07f_lenovo_sm_qm.xpfwext'", then more errors and timeouts.

[dmitriy-myz]

I think /usr/bin/validity-sensors-firmware should be run at least once to download firmware. It in install script, so in normal flow it should download it on install.

[Burghalim72]

I see, last time I checked it, it didn't work, so I thought it is some broken command. After running it, reset started working, but for some reason I need to run dbus_service three times after factory reset. First two times there is no output and it just stops after a while, and only on third run it resumes normal operation.

[dmitriy-myz]

Speaking of CPU usage on enroll: this is fine as instead of processing image directly on cpu it emulated in python code which is not efficient.
3 run of service is also kinda expected as after reset sensor rebooted three time:

1. reset blob + reboot
2. initial formatting + reboot
3. firmware upload + reboot

[Burghalim72]

Is emulated code going to be optimized later, if possible in Python?

I think the only issue that remains for sure (aside bugs that appear randomly) is broken deletion of individual fingers, which is annoying as it is not easy task to enroll all 10 fingers perfectly from first try. Can it be fixed?

[dmitriy-myz]

About optimization: I think no, enrollment is one-time operation to add finger into device DB So even if it CPU-expensive, I think this is fine. Regular finger recognition is done on chip and it the same as in Windows.

Deletion of all fingers is python-validity/fprintd responsibility as dbus-service only support to delete user from db. But you could stop python3-validity service and use script in this PR to list users/delete individual records

python scripts/enroll_moh_chip.py --list-users
...
2026-06-03 20:11:21,536 INFO     user dbid=4 identity=S-1-5-21-111111111-1111111111-1111111111-1000 fingers=2
2026-06-03 20:11:21,536 INFO       finger dbid=5 subtype=0x02
2026-06-03 20:11:21,536 INFO       finger dbid=6 subtype=0x03
python scripts/enroll_moh_chip.py --delete-dbid 6
...
2026-06-03 20:12:29,781 INFO ✓ deleted dbid=6
python scripts/enroll_moh_chip.py --list-users
...
2026-06-03 20:12:57,187 INFO     user dbid=4 identity=S-1-5-21-111111111-1111111111-1111111111-1000 fingers=1
2026-06-03 20:12:57,187 INFO       finger dbid=5 subtype=0x02

[Burghalim72]

for me it failed because it trying to override same finger

Is it intended behavior by the way? If yes, maybe it should return enroll-duplicate instead of retry-scan?

Also, is it possible to make backup of the sensor memory contents, and then restore it? Because I may want to spend some time trying to enroll my fingerprints perfectly (which is likely to take a lot of attempts and hours, including for testing after some time passes), but also be able to test the sensor in various modes.

[dmitriy-myz]

is it possible to make backup of the sensor memory contents, and then restore it

yes, sensor returns some finger data, but when I put it back it won't recognize finger. I think it should be possible to dump/restore but maybe there's some nuances.

[Burghalim72]

I noticed that if I interrupt enrolling (I place finger wrong/notice my finger became wet or sensor became dirty or whatever, so I press ^C with intention to try again a few seconds later), and then try again, it starts spamming verify-retry-scan, and it takes a few tries until it stops.

Factory reset remains unreliable. I am eventually able to reset by repeating the command, but sometimes from second or third attempt as errors or timeouts appear.