Package Details: python-validity 0.12-2

Git Clone URL: https://aur.archlinux.org/python-validity.git (read-only, click to copy)
Package Base: python-validity
Description: Validity fingerprint sensor driver
Upstream URL: https://github.com/uunicorn/python-validity
Licenses: MIT
Conflicts: python-validity
Provides: python-validity
Submitter: mattmurr
Maintainer: mattmurr
Last Packager: mattmurr
Votes: 7
Popularity: 1.07
First Submitted: 2020-07-12 21:33
Last Updated: 2020-10-20 07:57

Pinned Comments

kakawait commented on 2020-10-20 10:37

@cicagorio please do

sudo systemctl enable open-fprintd-suspend.service
sudo systemctl enable open-fprintd-resume.service

For more information see https://github.com/uunicorn/python-validity/issues/39#issuecomment-712395449

You may have to restart computer!

Latest Comments

« First ‹ Previous 1 2 3

niklaszantner commented on 2020-07-14 06:58

@aurelieng

  1. I think running sudo systemctl enable python3-validity is acutally not necessary, as the systemd entry should be called by the udev rule (I guess). My bad, sorry.

  2. I already ran into this issue and found that the following could help:

cd /usr/share/python-validity/playground/
sudo python3 factory-reset.py 

Info from upstream issue: https://github.com/uunicorn/python-validity/issues/3

I guess your fingerprint reader was already paired once (maybe on windows?) or somehow else already used.

After that, running

sudo systemctl start python3-validity
sudo systemctl status python3-validity

Should restart the service and check its status. udevadm control --reload-rules && udevadm trigger may also work, to reload the udev rule (see: https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot).

The only problem right now: On my machine, after resume from suspend (close lid, wait 10 seconds, open lid) the service is dead again :/ I did not find a solution for this yet.

aurelieng commented on 2020-07-14 06:49

t480s w/ Bus 001 Device 006: ID 06cb:009a Synaptics, Inc. here.

I followed the instructions https://aur.archlinux.org/packages/python-validity/#comment-755904 , and I see:

~ $ sudo systemctl enable python3-validity
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Then, sudo systemctl start python3-validity is silent (which might be expected?) but fprintd-enroll complains w/ list_devices failed:. Is this a problem with the package or with validity itself? I'd be happy to help debug this problem :-)

niklaszantner commented on 2020-07-13 17:43

Ok, I got it running via:

yay -S python-validity
sudo validity-sensors-firmware
sudo systemctl enable python3-validity
sudo systemctl start python3-validity
fprintd-enroll

And the enroll process worked just perfectly. @mattmurr Thank you very much! After two years, I am finally able to use the fingerprint reader on my t480s. Awesome :D

mattmurr commented on 2020-07-13 17:02

@niklaszantner: try running sudo validity-sensors-firmware to download the firmware manually.

niklaszantner commented on 2020-07-13 16:57

Thanks, I gave it another try:

● python3-validity.service - python-validity driver dbus service
     Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; static; vendor preset: disabled)
     Active: failed (Result: exit-code) since Mon 2020-07-13 18:49:46 CEST; 1min 47s ago
    Process: 29133 ExecStart=/usr/lib/python-validity/dbus-service --debug (code=exited, status=1/FAILURE)
   Main PID: 29133 (code=exited, status=1/FAILURE)

Jul 13 18:49:46 machine dbus-service[29133]:     open_common()
Jul 13 18:49:46 machine dbus-service[29133]:   File "/usr/lib/python3.8/site-packages/validitysensor/init.py", line 33, in open_common
Jul 13 18:49:46 machine dbus-service[29133]:     upload_fwext()
Jul 13 18:49:46 machine dbus-service[29133]:   File "/usr/lib/python3.8/site-packages/validitysensor/upload_fwext.py", line 52, in upload_fwext
Jul 13 18:49:46 machine dbus-service[29133]:     with open(fw_path, 'rb') as f:
Jul 13 18:49:46 machine dbus-service[29133]: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/python-validity/6_07f_lenovo_mis_qm.xpfwext'
Jul 13 18:49:46 machine python3[29133]: DEBUG:root:<int< Exception on interrupt thread: USBError(19, 'No such device (it may have been disconnected)')
Jul 13 18:49:46 machine python3[29133]: DEBUG:root:<int< Interrupt thread is dead

Looks like smth is either wrong with the download or extraction of the 6_07f_lenovo_mis_qm.xpfwext part of the windows driver. Or my setup.

mattmurr commented on 2020-07-13 16:50

@niklaszantner: I've just updated to use 0.7 tag and to use the included udev rule and systemd script (you should get some debug logging in journalctl now).

niklaszantner commented on 2020-07-13 16:09

I am currently running into the following issue:

18:04:56 ➜ sudo systemctl status python-validity.service 
● python-validity.service - python-validity dbus service
     Loaded: loaded (/usr/lib/systemd/system/python-validity.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Mon 2020-07-13 18:04:52 CEST; 4s ago
    Process: 12210 ExecStart=/usr/lib/python-validity/dbus-service (code=exited, status=1/FAILURE)
   Main PID: 12210 (code=exited, status=1/FAILURE)

Jul 13 18:04:52 machine systemd[1]: python-validity.service: Scheduled restart job, restart counter is at 5.
Jul 13 18:04:52 machine systemd[1]: Stopped python-validity dbus service.
Jul 13 18:04:52 machine systemd[1]: python-validity.service: Start request repeated too quickly.
Jul 13 18:04:52 machine systemd[1]: python-validity.service: Failed with result 'exit-code'.
Jul 13 18:04:52 machine systemd[1]: Failed to start python-validity dbus service.

journalctl -xe tells me:

-- The unit python-validity.service has entered the 'failed' state with result 'exit-code'.
Jul 13 18:09:35 machine systemd[1]: Failed to start python-validity dbus service.
-- Subject: A start job for unit python-validity.service has failed
-- Defined-By: systemd

Already ran the following commands (from https://github.com/uunicorn/python-validity/issues/3) and retried.

cd /usr/share/python-validity/playground/
sudo python3 factory-reset.py

Any idea?

Btw, version 0.7 with md5sum 9a327e7ff6cd55720d2cf62fa6d86b6b would be available ;) (see: https://github.com/uunicorn/python-validity/releases/tag/0.7)