guemidiborhane
commented
2 years ago how did you manage to fix this?
Open xyzshantaram opened 2 years ago
guemidiborhane
commented
2 years ago how did you manage to fix this?
xyzshantaram
commented
2 years ago I didn't, it's still broken.
guemidiborhane
commented
2 years ago Sorry I miss understood
On Fri, 7 Jan 2022, 8:20 pm Siddharth Singh, @.***> wrote:
I didn't, it's still broken.
— Reply to this email directly, view it on GitHub https://github.com/uunicorn/python-validity/issues/106#issuecomment-1007672940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7KVNYGORS4LN2QIQGJVUTUU44IHANCNFSM5LOGVKOA . You are receiving this because you commented.Message ID: @.***>
l4pa
commented
2 years ago i can confirm the issue on fully upgraded Arch, libusb error, i suppose it has to do with upgraded python. reinstalled libusb, no effect. same model of fingerprint reader.
l4pa
commented
2 years ago it only gets fixed for me if both python3-validity and open-fprintd are restarted.
l4pa
commented
2 years ago my log of open-fprintd-resume failure just in case
× open-fprintd-resume.service - Restart devices after resume Loaded: loaded (/usr/lib/systemd/system/open-fprintd-resume.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2022-01-12 22:14:20 EET; 8s ago Process: 4606 ExecStart=/usr/lib/open-fprintd/resume.py (code=exited, status=1/FAILURE) Main PID: 4606 (code=exited, status=1/FAILURE) CPU: 46ms
Jan 12 22:14:20 zzz resume.py[4606]: File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write Jan 12 22:14:20 zzz resume.py[4606]: return self.write(self.lib.libusb_bulk_transfer, Jan 12 22:14:20 zzz resume.py[4606]: File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in write Jan 12 22:14:20 zzz resume.py[4606]: _check(retval) Jan 12 22:14:20 zzz resume.py[4606]: File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check Jan 12 22:14:20 zzz resume.py[4606]: raise USBError(_strerror(ret), ret, _libusb_errno[ret]) Jan 12 22:14:20 zzz resume.py[4606]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected) Jan 12 22:14:20 zzz systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE Jan 12 22:14:20 zzz systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'. Jan 12 22:14:20 zzz systemd[1]: Failed to start Restart devices after resume.
sarlej
commented
2 years ago I have same issue, what helps for me as workaround is restarting open-fprintd and python3-validity as l4pa suggested. Also this issue dosn't happened every time i wake up computer from suspend. It started cca month ago. My device ID: 138a:0097 Validity Sensors, Inc. Im using version 0.12-4 from AUR python-validity package Output of journalctl -u open-fprintd-resume.service
led 18 08:45:47 jntb systemd[1]: Starting Restart devices after resume...
led 18 08:45:47 jntb resume.py[38662]: Traceback (most recent call last):
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/open-fprintd/resume.py", line 11, in <module>
led 18 08:45:47 jntb resume.py[38662]: o.Resume()
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/dbus/proxies.py", line 141, in __call__
led 18 08:45:47 jntb resume.py[38662]: return self._connection.call_blocking(self._named_service,
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/dbus/connection.py", line 652, in call_blocking
led 18 08:45:47 jntb resume.py[38662]: reply_message = self.send_message_with_reply_and_block(
led 18 08:45:47 jntb resume.py[38662]: dbus.exceptions.DBusException: org.freedesktop.DBus.Python.Exception: Traceback (most recent call last):
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/dbus/service.py", line 715, in _message_cb
led 18 08:45:47 jntb resume.py[38662]: retval = candidate_method(self, *args, **keywords)
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python-validity/dbus-service", line 74, in Resume
led 18 08:45:47 jntb resume.py[38662]: init.open_common()
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/validitysensor/init.py", line 29, in open_common
led 18 08:45:47 jntb resume.py[38662]: init_flash()
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/validitysensor/init_flash.py", line 113, in init_flash
led 18 08:45:47 jntb resume.py[38662]: info = get_flash_info()
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/validitysensor/flash.py", line 41, in get_flash_info
led 18 08:45:47 jntb resume.py[38662]: assert_status(rsp)
led 18 08:45:47 jntb resume.py[38662]: File "/usr/lib/python3.10/site-packages/validitysensor/util.py", line 12, in assert_status
led 18 08:45:47 jntb resume.py[38662]: raise Exception('Failed: %04x' % s)
led 18 08:45:47 jntb resume.py[38662]: Exception: Failed: 0315
led 18 08:45:47 jntb systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE
led 18 08:45:47 jntb systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'.
led 18 08:45:47 jntb systemd[1]: Failed to start Restart devices after resume.
ioanmoldovan95
commented
2 years ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit]
Description=Restart services to fix fingerprint integration
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
[Service]
Type=oneshot
ExecStart=systemctl restart open-fprintd.service python3-validity.service
[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target@ioanmoldovan95 Thanks! I was considering doing something like that myself, you're a lifesaver! <3
saunite
commented
2 years ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit] Description=Restart services to fix fingerprint integration After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=systemctl restart open-fprintd.service python3-validity.service [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
This worked perfectly for me on a Lenovo T480s running Fedora 36
SoEven
commented
2 years ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit] Description=Restart services to fix fingerprint integration After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=systemctl restart open-fprintd.service python3-validity.service [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
Just tried this on my T480 running Fedora 36. Works like a charm!
ekirchman
commented
2 years ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit] Description=Restart services to fix fingerprint integration After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=systemctl restart open-fprintd.service python3-validity.service [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.targetJust tried this on my T480 running Fedora 36. Works like a charm!
Also running Fedora 36 with a T480, although I've noticed that at least with KDE plasma, only about half the time I'm prompted for a fingerprint. The other times I need to put in a bad password once before it prompts for a fingerprint. Maybe the services don't restart fast enough for the device to register?
Edi: It does seem like a timing thing. Waiting a second or two before hitting the enter key on the lock screen makes it so the fingerprint reader always comes up. But because I'm always faster than that 2 second wait, it doesn't prompt on first try :(
latenightdef
commented
1 year ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit] Description=Restart services to fix fingerprint integration After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=systemctl restart open-fprintd.service python3-validity.service [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
This worked great on my T480s running Fedora 37 Beta, thanks!
perezandrew477
commented
1 year ago I have the same issue as the one described above. I have solved it by writing a service that runs after resume and restarts open-fprintd and python3-validity services It's a quick and easy fix until a permanent fix is found I'll leave the code for this service below for anyone who might need it.
[Unit] Description=Restart services to fix fingerprint integration After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=systemctl restart open-fprintd.service python3-validity.service [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.targetJust tried this on my T480 running Fedora 36. Works like a charm!
Also running Fedora 36 with a T480, although I've noticed that at least with KDE plasma, only about half the time I'm prompted for a fingerprint. The other times I need to put in a bad password once before it prompts for a fingerprint. Maybe the services don't restart fast enough for the device to register?
Edi: It does seem like a timing thing. Waiting a second or two before hitting the enter key on the lock screen makes it so the fingerprint reader always comes up. But because I'm always faster than that 2 second wait, it doesn't prompt on first try :(
Tried this fix as well and I'm experiencing the same behavior. If I get pass the lock screen too quickly, I won't be able to use the fingerprint reader to login. If I wait a second or two, it works just fine and I can login with my fingerprint. I don't really mind waiting a second or two, but hopefully this can be improved upon. Thanks @ioanmoldovan95!
I'm running Fedora 36 on a T480.
Grafcube
commented
1 year ago I fixed this issue for myself with the solution in this thread and it worked perfectly on my Thinkpad running latest Arch. Is there any particular reason that this fix hasn't been included in the main package?
Edit: It seems like it's a little inconsistent. I'm experiencing the same delay issue as the above comment. I don't mind too much since it still works but it hopefully it can be fixed.
ioanmoldovan95
commented
1 year ago Yes, I am aware about the issue that is described in the last few comments, but haven't found a solution to it yet as it doesn't bother me too much, I prefer to wait 1-2 seconds before tapping enter to bring up the login screen. It is for sure a timing issue, the services are not restarted as fast as they should. If I come up with a solution I will post it here
coignard
commented
6 months ago You can also enable services that come with the python-validity package instead of creating a new one:
systemctl enable python3-validity-restart-after-resume.service open-fprintd-restart-after-resume.service
Works like a charm.
cg505
commented
6 months ago @coignard What package are you using? I don't see those service files in this repo or in the AUR packages.
coignard
commented
6 months ago @coignard What package are you using? I don't see those service files in this repo or in the AUR packages.
tigro/python-validity copr on Fedora.
poopsicles
commented
1 month ago simply restarting python3-validity manually allows me to use fingerprint auth (with fprintd-verify for example) after unlocking from suspend, and enabling python3-validity-restart-after-resume lets it work on the lock screen, with a caveat.
if you get past the lock screen clock in GNOME, the service isn't restarted in time which allows you to only use your password to log in (as shown in earlier comments). however, for some reason, my install of fedora skips the clock (i can see it flash by really quick), thereby dumping my at the password entry...after logging in though, fprintd-verify works fine.
This Gitlab issue also seems to be about the same thing, and as a workaround tapping Esc (to go back to the clock) and then Enter again loads it correctly.
For reference, I'm using a ThinkPad T480s and Fedora 40 (but it's a mostly fresh install, haven't gotten around to sudo dnf updateing, maybe that would fix the problem.
meandyc
commented
3 weeks ago Works in Debian 12 (T480) too.
It is fixed upon restarting, but fails upon resuming from suspend again. This is on Arch Linux with the
python-validity-gitAUR package, and my FPR is06cb:009aSynaptics, Inc. Metallica MIS Touch Fingerprint Reader.Output of
systemctl status open-fprintd-resume.service:Output of
sudo systemctl start open-fprintd-resume.service:Output of
journalctl -xeu open-fprintd-resume.service:I also tried it with the regularpython-validityAUR package (which doesn't seem to have been updated to 0.13 yet?), but that also caused the service with a different error -- I'll post the details in a follow-up comment.Edit: I'm unable to reproduce that error anymore, it was a USBError from pyusb stating that the device couldn't be found and that it may have been disconnected. Now, both the
-gitand normal versions report the same error.