fprintd-enroll fails with 138a:0090 ? about python-validity

[himekifee]

Did you pair the sensor with pc use validity tools?

[dlarrick]

Thanks for the suggestion. My understanding is the dbus-service does pairing automatically at startup if necessary.

If I manually run validitysensor.init.open() from a Python shell as root it succeeds, so I think that means it's paired. If I open permissions on the USB device and do that as a normal user it complains Signature verification failed. This device was probably paired with another computer.

[himekifee]

Not the same pairing. Ur one is SSL pairing which is as what you said but there is another pairing which do reset factory, flash firmware and calibrate. That is done by using validity tools, could you try that first please.

[dlarrick]

Are you referring to the commands under "Error situations" section in the main README?

$ sudo systemctl stop python3-validity
$ sudo validity-sensors-firmware
$ sudo python3 /usr/share/python-validity/playground/factory-reset.py

Yes, I did that. Or is there some other command?

[himekifee]

You need to wait for uunnicorn to respond then. I'm not sure about the code. You can try to do that several times though. In addition, 0097 and 0090 have the same size. I replaced my 0090 with 0097. 0097 is match on chip so faster and more accurate.

[uunicorn]

Hi,

0090 is a match-on-host device, as far as I know.
python-validity was never designed to support this mode of operation. It is currently only supports enrolling/identifying on match-on-sensor devices.
It does however support the pairing and flashing of 0090 devices - this feature was used by a @3v1n0 's pairing tool from his fprintd branch.

[dlarrick]

Ahh, now it makes sense. Yes, 0090 is a match-on-host device, or at least nobody has ever figured out how to make it do match-on-device. Thanks. I'm closing this issue.