Arch linux, 06cb:009a. After update exiting sleep mode it gives an error

[Spbog]

after the update the problem occurs. After the system starts, the fingerprint works, but if you put the laptop into sleep mode and exit, then the fingerprint will stop working everywhere.

if I try to write the fprintd-validity command, then it gives an error

Using device /net/reactivated/Fprint/Device/1
ListEnrolledFingers failed: Traceback (most recent call last):
 File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in _message_cb
 retval = candidate_method(self, *args, **keywords)
 File "/usr/lib/python-validity/dbus-service", line 92, in ListEnrolledFingers
 raise e
 File "/usr/lib/python-validity/dbus-service", line 83, in ListEnrolledFingers
 usr = self.user2record(user)
 File "/usr/lib/python-validity/dbus-service", line 63, in user2record
 return db.lookup_user(self.user2identity(user))
 ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/lib/python3.13/site-packages/validitysensor/db.py", line 163, in lookup_user
 stg = self.get_user_storage(name='StgWindsor')
 File "/usr/lib/python3.13/site-packages/validitysensor/db.py", line 149, in get_user_storage
 return parse_user_storage(tls.cmd(pack('<BHH', 0x4b, dbid, len(name)) + name))
 ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/lib/python3.13/site-packages/validitysensor/tls.py", line 122, in cmd
 rsp = self.app(cmd)
 File "/usr/lib/python3.13/site-packages/validitysensor/tls.py", line 152, in app
 return self.parse_tls_response(self.usb.cmd(self.make_app_data(b)))
 ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/lib/python3.13/site-packages/validitysensor/tls.py", line 351, in parse_tls_response
 raise Exception('Unexpected TLS version %d %d' % (mj, mn))
Exception: Unexpected TLS version 4 0

running the open-fprintd-resume and open-fprintd-suspend services does not help

kernel: 6.13.1-arch2-1
fingerprint reader: Bus 001 Device 006: ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader

[dmig]

Something is breaking in the recent arch updates: first I tried to reenroll fingers and it always failed, I reset the sensor, reenrolled and now getting the same exception. Will investigate it.

[Spbog]

Something is breaking in the recent arch updates: first I tried to reenroll fingers and it always failed, I reset the sensor, reenrolled and now getting the same exception. Will investigate it.

u reset sensor in BIOS? if yes, now you need to boot windows, and them register the useless finger. idk why this happening, but it helps.

and also, problem with "TLS" fixed after reinstall arch. and now fprintd works fine

[dmig]

there is factory-reset script in this package.

and also, problem with "TLS" fixed after reinstall arch. and now fprintd works fine

...until you update some tls library

[ixnewton]

I re-installed all fprintd, libfprint-tod, fprintd-clients and python-validity. Fingerprint unlock etc is working as before without re-training the fingerprints, however resume and unlock (Lightdm) results in the following crash/error at usb.py.

exception.txt

Device 004: ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader
Linux 6.14.0-rc4-1-MANJARO

The resulting login from suspend takes about 30s to show the desktop with a black screen persisting with only the mouse cursor active.

[ixnewton]

This problem appears to be resolved for my sensor and maybe for others:
Device 004: ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader
Linux 6.14.0-rc4-1-MANJARO

This may be a result of the most recent Linux firmware update:
[2025-03-18T21:29:38+0000] [ALPM] upgraded linux-firmware-whence (20250311.b69d4b74-1 -> 20250311.b69d4b74-2)
[2025-03-18T21:29:40+0000] [ALPM] upgraded linux-firmware (20250311.b69d4b74-1 -> 20250311.b69d4b74-2)
[2025-03-18T21:29:40+0000] [ALPM] upgraded linux-firmware-qlogic (20250311.b69d4b74-1 -> 20250311.b69d4b74-2)

Now there is no longer a crash of python-validity on resume due to the sensor not being detected/connected. It was previously recovered by the python3-validity-suspend-hotfix.service but not 100% of the time.

The 30 second delay in logging in no longer happens, so all good for now!

[uunicorn]

Hi All,

Suspend/resume behavior is weird because it is inconsistent. Sometimes suspend / resume leads to sensor USB device to disconnect / reconnect and sometimes it doesn't. open-fprintd-suspend.service and open-fprintd-resume.service intended to help with the cases when USB device doesn't get disconnected during suspend. However, open-fprintd was still broken when USB device reconnects during suspend / resume. I think I've fixed it now. Can you try removing workarounds like python3-validity-suspend-hotfix and reinstall the latest versions of open-fprintd, python-validity and fprintd-clients? I've published fresh versions to PPA, but it probably does not help much, given you're on Arch.

[dmig]

@uunicorn I implemented this: uunicorn/open-fprintd#12 (comment) and it works perfectly. No gross hacks needed.

[uunicorn]

@dmig , yes, explicitly setting power/persist=1 (which supposed to be the default) fixes the problem with a disconnecting usb device. However, that is not a good excuse for not handling usb reconnects gracefully. As a bonus, the fingerprint option is now available the first time after suspend: no need to hit escape to cancel the password prompt to get the fingerprint option.

In theory adding power/persist=1 makes the finger prompt appear faster after resume. In practice I can't notice a significant improvement: the slowest part of the setup is the establishment a TLS session, which we have to do in both cases anyway.

[pcfighter]

I believe on most "restart after resume" services the problem is that it's trying to restart service when device is not ready.
I recently learned that you can use .path unit with path to the sensor defined and override service to require it - it is needed as systemd does not create .device unit for sensor for some reason.
Having service to restart python-validity like python3-validity-restart-after-resume.service, used systemctl edit to add this:

[Unit]
Requires=python3-validity-restart-after-resume.path

where .path unit is defined like this:

[Unit]
Description=Watch for fingerprint scanner device path

[Path]
PathExists=/devices/pci0000:00/0000:00:14.0/usb1/1-9

[Install]
WantedBy=multi-user.target

while /devices(...) doesn't seem to be a real path, querying udevadm info /sys/devices/pci0000:00/0000:00:14.0/usb1/1-9
returns this path as DEVPATH so I guess that's how it works. .path unit doesn't seem to require enabling as this works as a trigger to start a service.