Working with 06cb:009a Synaptics, Inc.

[javierfileiv]

Hi there, I'm trying to make work this fp.

I saw that there are blobs_90.py are blobs_97.py . Are these binary blobs taken from the firmware extracted from the windows installer?

How can I know which one is init_hardcoded , init_hardcoded_clean_slate, etc ?

Thanks for your reply

[uunicorn]

Are these binary blobs taken from the firmware extracted from the windows installer?

I'm quite confident these blobs are pieces of code which Windows driver dynamically uploads and executes on the device. They are hard-coded inside the driver .dll.

How can I know which one is init_hardcoded , init_hardcoded_clean_slate, etc ?

You can use this project https://github.com/uunicorn/synaWudfBioUsb-sandbox to snoop on Windows driver to see which blobs are loaded into your device and when.

[storm1ng]

The firmware's name for 009a is 6_07f_lenovo_mis_qm.xpfwext (extracted from nz3gf07w.exe.

I will try and extract the blobs. Let's see how it goes.

[javierfileiv]

Thanks @mjenny , could you please share after the extract? :)

[storm1ng]

@javierfileiv sure, if I'm able to extract them. :)
I'm currently in the process of compiling wine.

[uunicorn]

I can assist you in finding the blobs if you can manage to get synaWudfBioUsb-sandbox running.
In addition to the firmware file itself, you will also need to extract synawudfbiousb.dll from your Windows diver.
If all good, wine64 a.exe will spit tons of output. Redirect it to a file and upload somewhere so I can have a look.
Good luck.

[storm1ng]

@uunicorn I already have the DLL and the firmware extracted. I will let you know as soon as I have wine up and running.

I am currently compiling wine inside a VM running on my Lenovo X1 Extreme. Not sure if that will be sufficient. If not I will install Arch Linux or Linux Mint for a faster install. 😄

[storm1ng]

Hm... I should have tried to passthrough the fingerprint reader earlier. I guess Intel Secure Guard Extension is a problem or the fact that I have enabled WSL2 and have to go through Hyper-V.

[storm1ng]

@uunicorn do I have to put the firmware file somewhere to run a.exe?

[uunicorn]

Both .xpfwext and .dll should be placed in the same directory with a.exe.

I'm no expert, but if you're running a host on Windows, it may be hard to pass the reader USB device to a Linux guest. Windows diver may have claimed the same device and could interfere with a communication. But yeah, IDK, I never tried that.

[storm1ng]

@uunicorn I installed Linux Mint for now. Will do everything over again.
Am I still supposed to compile wine myself (regarding hacks)?

[uunicorn]

Yes. Hacks have a bunch of printfs sprinkled all over the crypto routines. Those are actually used to dump all the communication between a device and a driver. Including the missing blobs.
Hacks also include a fake winusb.dll implementation which lets synawudfbiousb.dll talk to a real USB device. Vanilla wine does not have this DLL.

Which reminds me that you'd probably want to change this line before building Wine:
https://github.com/uunicorn/wine/blob/7ed3db9743a525228fb6306ab0d8d0f8b4163e00/dlls/winusb/winusb.c#L16

[storm1ng]

I'm currently back to building wine with the aforementioned changes.

[storm1ng]

@uunicorn I successfully built wine and it worked fine so far. However, I don't have a wine64 executable. And when running WINEARCH=~/.wine-fingerprint wine a.exe I get a wine: Bad EXE format for Z:\home\mjenny\wine\a.exe..

I assume that a.exe which I downloaded directly from your repo (I didn't build it myseld) is using 64-bit, right (a.exe: PE32+ executable (console) x86-64, for MS Window)?

Do I have to build wine differently?

[storm1ng]

Nvm, I missed --enable-win64...

[storm1ng]

Ok, I have everything running.

@uunicorn how do I know that a.exe was successfully run? I am now getting a Program Error during execution.
There seems to be an Unhandled page fault:

USB >>>>>>>>>> In DllMain reason=1
USB >>>>>>>>>> WinUsb_Initialize
wine: Unhandled page fault on read access to 0x00000040 at address 0x7f1005121a44 (thread 0009), starting debugger...

[storm1ng]

@uunicorn here is the link to the logfile: logfile.txt

[uunicorn]

@mjenny it looks like it crashed because it failed to find your USB device.

Can you check that the device vendor and the product id in /dlls/winusb/winusb.c are actually matching your hardware?

By default it is

#define MY_VENDOR   0x138a
#define MY_PRODUCT  0x0097

which corresponds to 0097 device. If you have a 009a, you should probably change MY_PRODUCT to 0x009a, but it would be best if you can double check with lsusb:

$ lsusb 
...
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc. <---- my device
...
$ 

how do I know that a.exe was successfully run?

a.exe should let you enroll a finger.

[storm1ng]

I should have known it better... I was thinking about changing #define MY_VENDOR to 06cb which is what my lsusb is printing:

...
Bus 001 Device 003: ID 06cb:009a Synaptics, Inc.
...

I'll rebuild wine then and let you know how it goes.

[storm1ng]

@uunicorn
It looks better know. Do I have to run wine64 as root to be able to access the USB device?

0009:trace:reg:NtQueryValueKey (0x60,L"SignatureKeyPair",2,0x332d20,256)
USB >>>>>>>>>> In DllMain reason=1
USB >>>>>>>>>> WinUsb_Initialize
!!!!!!!!!!!! Found device 06cb:009a
libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/003: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
Failed 'libusb_open(dev_list[i], &info->dev)': -3 - LIBUSB_ERROR_ACCESS
0010:trace:reg:open_key ((nil),L"\\Registry\\Machine\\System\\CurrentControlSet\\Control\\ComputerName",20019,0x7df700)
0010:trace:reg:open_key <- 0xb8
0010:trace:reg:open_key (0xb8,L"ActiveComputerName",20019,0x7df708)
0010:trace:reg:open_key <- 0x15c
0010:trace:reg:NtQueryValueKey (0x15c,L"ComputerName",2,0x7df750,44)
0010:trace:reg:open_key ((nil),L"\\Registry\\Machine\\System\\CurrentControlSet\\Control\\ComputerName",20019,0x7df700)
0010:trace:reg:open_key <- 0x168
0010:trace:reg:open_key (0x168,L"ActiveComputerName",20019,0x7df708)
0010:trace:reg:open_key <- 0x15c
0010:trace:reg:NtQueryValueKey (0x15c,L"ComputerName",2,0x7df750,44)
002e:trace:reg:RegDeleteTreeW (0x24, L"Winedevice1")
002e:trace:reg:open_key (0x24,L"Winedevice1",20019,0x1c7fa98)
002e:trace:reg:open_key <- (nil)
0010:trace:reg:RegDeleteTreeW (0x24, L"Winedevice2")
0010:trace:reg:open_key (0x24,L"Winedevice2",20019,0x7dfaa8)
0010:trace:reg:open_key <- (nil)

[uunicorn]

I've got a custom udev rule:

/etc/udev/rules.d/10-fpreader.rules:ATTRS{idVendor}=="138a", ATTRS{idProduct}=="0097", OWNER="unicorn"

But you can chown it manually. It's gonna be reset after reboot or when device re-connects.

[storm1ng]

@uunicorn I chowned the device and the logfile.txt looks promissing: logfile.txt
However, I still was not able to enroll a finger.

>>>>>>>>>>> xfer Failed - LIBUSB_ERROR_NO_DEVICE

[uunicorn]

That could mean that device just finished pairing and has restarted.
Chown again and give it another go. It may take a couple of tries.

[uunicorn]

Or may be not.
I can't see it's sending any firmware. But the last message the host sent to a device was a "reboot" command (which caused USB device to disconnect):

USB a03700 >>>>>>>>>> WinUsb_WritePipe PipeID=1
>>> 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
rc=0 send=98

You may need to put the firmware file in some other place, where the driver is looking for it. Not sure where though.

[storm1ng]

I couldn't find anything in regards to that inside synaWudfBioUsbLenovoMiSSGXProd.inf (which is the only inf file I could find): synaWudfBioUsbLenovoMiSSGXProd.inf

[uunicorn]

What do you mean? Here it is:

[DestinationDirs]
...
WinBioSensorAdapterCopy=11, WinBioPlugins; copy to \Windows\System32\WinBioPlugins
FWextCopy=11
...
[FWextCopy]
6_07f_lenovo_mis_qm.xpfwext
...

Try copying it to \Windows\System32\WinBioPlugins in your Wine prefix.
E.g ~/.wine/driver_c/Windows/System32/WinBioPlugins/
You may need to create WinBioPlugins directory.

[storm1ng]

Dang, I missed that completely...
It is now using the firmware file from what I can tel. However, the result is the same, no matter how many times I try. The pairing is working fine and it will be recognized as new USB device for which my user is still the owner.
ls -la /dev/bus/usb/001
Before the run:

total 0
drwxr-xr-x 2 root   root     160 Jun 22 06:53 .
drwxr-xr-x 6 root   root     120 Jun 22 05:56 ..
crw-rw-r-- 1 root   root 189,  0 Jun 22 05:56 001
crw-rw-r-- 1 root   root 189,  1 Jun 22 05:56 002
crw-rw-r-- 1 root   root 189,  3 Jun 22 05:56 004
crw-rw-r-- 1 root   root 189,  4 Jun 22 05:56 005
crw-rw-r-- 1 root   root 189,  5 Jun 22 05:56 006
crw-rw-r-- 1 mjenny root 189, 16 Jun 22 06:53 017

After the run:

total 0
drwxr-xr-x 2 root   root     160 Jun 22 06:54 .
drwxr-xr-x 6 root   root     120 Jun 22 05:56 ..
crw-rw-r-- 1 root   root 189,  0 Jun 22 05:56 001
crw-rw-r-- 1 root   root 189,  1 Jun 22 05:56 002
crw-rw-r-- 1 root   root 189,  3 Jun 22 05:56 004
crw-rw-r-- 1 root   root 189,  4 Jun 22 05:56 005
crw-rw-r-- 1 root   root 189,  5 Jun 22 05:56 006
crw-rw-r-- 1 mjenny root 189, 16 Jun 22 06:54 018

logfile.txt
I'll continue to try.

[storm1ng]

Do you think that the new device number is the issue and that xfer can no longer find the device?

[uunicorn]

No, host is requesting device to reboot before it disconnects. USB comms are fine.
By the looks of it, the device was not partitioned properly yet.
I'll have a closer look in a while, thanks for trying - some of the blobs are already in the output.
Did you capture the output from all your attempts?

[storm1ng]

No, but I can create a few more and upload them if it helps.

[uunicorn]

Can you use factory-reset.py and try again?
Try to log everything when running a.exe, as the device has a state and running it twice in a row may give different results.

[peterbabic]

Hello, great work! I am very thankful for this project.
However, this thread is quite long and is discussing multiple issues. Could there please be a separate issue thread to just track the "make it work after suspend" status, please? I do have a 0097 sensor, yet the information about suspend issue spread here in the thread for 009a and there are also multiple mentions in the AUR.

[uunicorn]

Hi @ros86 ,

Well, this is embarrassing. I forgot to push recent changes to PPA. Including the SID mapping README is talking about. I've just published 0.11, which should contain these changes - please update and try again.

@peterbabic good point. It is very hard to find anything ITT. Now that it seems 009a is supported, we can probably close this issue. Feel free to raise a new one about resuming after suspend.

[ros86]

@uunicorn 0.11 version works perfectly! 😃 many thanks!

Sorry to everybody for incorrect issue of post

[bingch]

Hi Peter, I also experineced the suspend issue on my X1's 009a sensor when I try using uunicorn's open-fprintd a while ago, so I forked marco's libfprint-tod-vfs0090 driver in my repo ( https://gitlab.com/bingch/libfprint-tod-vfs0090), made some changes so it works for 009a too. As this setup uses the upstream fprintd instead, suspend works well, it might work for your 0097 sensor too. Note you still need to use uunicorn's python-validity package to initialize and enroll fingerprint

…

On Thu, 2020-09-10 at 01:00 -0700, Peter Babič wrote: Hello, great work! I am very thankful for this project. However, this thread is quite long and is discussing multiple issues. Could there please be a separate issue thread to just track the "make it work after suspend" status, please? I do have a 0097 sensor, yet the information about suspend issue spread here in the thread for 009a and there are also multiple mentions in the AUR. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[kakawait]

Hi @ros86 ,

Well, this is embarrassing. I forgot to push recent changes to PPA. Including the SID mapping README is talking about. I've just published 0.11, which should contain these changes - please update and try again.

@peterbabic good point. It is very hard to find anything ITT. Now that it seems 009a is supported, we can probably close this issue. Feel free to raise a new one about resuming after suspend.

FYI I've edit Arch T480s wiki page to set Fingerprint reader to "Y" instead of "N" 👍

https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_T480s#Fingerprint_Reader

PS: first contribution to Arch wiki so feel free to improve if needed.

[bobesku]

Hello, I am trying to make this work for 06cb:00be Synaptics and have a couple of questions:
Is this compatible with the above? Is it just a matter of finding the blobs and do some coding to also support the 06cb:00be?
Thanks

[bobesku]

I've started to move forward with attempts to grab the blobs, but only to find issues on my machine with https://github.com/uunicorn/synaWudfBioUsb-sandbox. I managed to make the setup and tried to run it but have several errors regarding missing DLL files. Check this out: https://pastebin.com/YMyMmKwA
I think I am stuck.... for now :)

[georgms]

Just wanted to say that I am successfully using a 06cb:009a fingerprint on a Lenovo Thinkpad X1 Carbon 8th Gen to login to Ubuntu. Thank you so much for your work!

[jja2000]

Hi! I'm trying python-validity on my A485 which has the sensor with this USB id, but I'm running into a problem where python runs into the following exception:

● python3-validity.service - python-validity driver dbus service
     Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-09-02 11:55:09 CEST; 10min ago
   Main PID: 9253 (dbus-service)
      Tasks: 3 (limit: 17764)
     Memory: 18.7M
        CPU: 322ms
     CGroup: /system.slice/python3-validity.service
             └─9253 /usr/bin/python3 /usr/lib/python-validity/dbus-service --debug

sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>tls> 17: 39f4010000f401000001ff002000000000ffff0000000000000000000000000020000000000000000000000000f401000000ff0020000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>cmd> 17030300b0528cc661af7d914fd7b57f086da5a33b1b56429cc18afd43941bed6506d822cbce2835df7add725e3defd6bceb920fdd8ac7918524dfe6c66122d20b4e45e2aac935cf3c1f3913810b37f35a33a68e331bd175952166c2f4ed313bbf59ab815862a1031a8bace403a9fb54bd633fc64be99b1f6a1a0b14f3750c75bc6a3313e8c2c6d966696aed1fa1ee70e08079f2e5bfee4951eca21b60117b1134bb2b0ca46dce9caeb64e39ce32fd456272d531fa
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<cmd< 1703030040cb722b98f79e1044bd445d80d2e4cc5ce20c7b0ae2d0c9b2654ec3156fd60fc1bed9a4ce3481d4f63bc2f7cd41bf860c33f315e2922a1dccc954ee6cae08db8c
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<tls< 17: 0000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>tls> 17: 6900000000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>cmd> 1703030040e89f9726839eb65a57825f6b6e042127f68dfcc9448f086e57eea45b29fd27fdc3ac57d300f1fe02a6fbe23eb123fb4fd49a7008dfdf55295437a0db8f35bf13
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<cmd< 17030300402094f9920aece10093cce66a1aee92d1360caa8b05c8a0c6a9eae1cac590c46dff40eb63e4adc144100f6a47fa1d4eb578cf089dfa41646e9cc96ab226b3745c
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<tls< 17: 0000
sep 02 12:02:41 AyyMDenkplank ERROR:root[9253]: Traceback (most recent call last):
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/usb.py", line 128, in wait_int
                                                    resp = self.dev.read(131, 1024, timeout=100)
                                                  File "/usr/lib/python3.9/site-packages/usb/core.py", line 983, in read
                                                    ret = fn(
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in intr_read
                                                    return self.__read(self.lib.libusb_interrupt_transfer,
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 936, in __read
                                                    _check(retval)
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 595, in _check
                                                    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
                                                usb.core.USBError: [Errno 110] Operation timed out
                                                
                                                During handling of the above exception, another exception occurred:
                                                
                                                Traceback (most recent call last):
                                                  File "/usr/lib/python-validity/dbus-service", line 161, in run
                                                    sensor.enroll(usr, index, update_cb)
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 844, in enroll
                                                    raise e
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 832, in enroll
                                                    self.capture(CaptureMode.ENROLL)
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 711, in capture
                                                    b = usb.wait_int()
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/usb.py", line 135, in wait_int
                                                    raise CancelledException()
                                                validitysensor.usb.CancelledException
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:EnrollStatus

It seems like it has something to do with USB timing out, at least that's what the error says. The light above the sensors flashes shortly on starting the enroll and killing it. Swiping my finger across does nothing.

[YasinLaw]

Hi! I'm trying python-validity on my A485 which has the sensor with this USB id, but I'm running into a problem where python runs into the following exception:

● python3-validity.service - python-validity driver dbus service
     Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-09-02 11:55:09 CEST; 10min ago
   Main PID: 9253 (dbus-service)
      Tasks: 3 (limit: 17764)
     Memory: 18.7M
        CPU: 322ms
     CGroup: /system.slice/python3-validity.service
             └─9253 /usr/bin/python3 /usr/lib/python-validity/dbus-service --debug

sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>tls> 17: 39f4010000f401000001ff002000000000ffff0000000000000000000000000020000000000000000000000000f401000000ff0020000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>cmd> 17030300b0528cc661af7d914fd7b57f086da5a33b1b56429cc18afd43941bed6506d822cbce2835df7add725e3defd6bceb920fdd8ac7918524dfe6c66122d20b4e45e2aac935cf3c1f3913810b37f35a33a68e331bd175952166c2f4ed313bbf59ab815862a1031a8bace403a9fb54bd633fc64be99b1f6a1a0b14f3750c75bc6a3313e8c2c6d966696aed1fa1ee70e08079f2e5bfee4951eca21b60117b1134bb2b0ca46dce9caeb64e39ce32fd456272d531fa
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<cmd< 1703030040cb722b98f79e1044bd445d80d2e4cc5ce20c7b0ae2d0c9b2654ec3156fd60fc1bed9a4ce3481d4f63bc2f7cd41bf860c33f315e2922a1dccc954ee6cae08db8c
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<tls< 17: 0000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>tls> 17: 6900000000
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:>cmd> 1703030040e89f9726839eb65a57825f6b6e042127f68dfcc9448f086e57eea45b29fd27fdc3ac57d300f1fe02a6fbe23eb123fb4fd49a7008dfdf55295437a0db8f35bf13
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<cmd< 17030300402094f9920aece10093cce66a1aee92d1360caa8b05c8a0c6a9eae1cac590c46dff40eb63e4adc144100f6a47fa1d4eb578cf089dfa41646e9cc96ab226b3745c
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:<tls< 17: 0000
sep 02 12:02:41 AyyMDenkplank ERROR:root[9253]: Traceback (most recent call last):
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/usb.py", line 128, in wait_int
                                                    resp = self.dev.read(131, 1024, timeout=100)
                                                  File "/usr/lib/python3.9/site-packages/usb/core.py", line 983, in read
                                                    ret = fn(
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in intr_read
                                                    return self.__read(self.lib.libusb_interrupt_transfer,
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 936, in __read
                                                    _check(retval)
                                                  File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 595, in _check
                                                    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
                                                usb.core.USBError: [Errno 110] Operation timed out
                                                
                                                During handling of the above exception, another exception occurred:
                                                
                                                Traceback (most recent call last):
                                                  File "/usr/lib/python-validity/dbus-service", line 161, in run
                                                    sensor.enroll(usr, index, update_cb)
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 844, in enroll
                                                    raise e
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 832, in enroll
                                                    self.capture(CaptureMode.ENROLL)
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 711, in capture
                                                    b = usb.wait_int()
                                                  File "/usr/lib/python3.9/site-packages/validitysensor/usb.py", line 135, in wait_int
                                                    raise CancelledException()
                                                validitysensor.usb.CancelledException
sep 02 12:02:41 AyyMDenkplank dbus-service[9253]: DEBUG:root:EnrollStatus

It seems like it has something to do with USB timing out, at least that's what the error says. The light above the sensors flashes shortly on starting the enroll and killing it. Swiping my finger across does nothing.

same issue

[YasinLaw]

@jja2000 I just found solution here

factory-reset and then works.

[l4pa]

made some changes so it works for 009a too. As this setup uses the upstream fprintd instead, suspend works well, it might work for your 0097 sensor too.

thank you! i wish i came across your repository sooner. with your help 009a in my T480s works with "standard" fprintd now. suspend issue is now gone. thank you again.

[bingch]

glad to hear it works on T480s too

[godfuzz3r]

Have an issue after suspend on t480s: if open-fprintd-resume and open-fprintd-suspend disabled then there is [Errno 19] No such device (it may have been disconnected) error when trying to use reader (message comes from /usr/lib/open-fprintd/resume.py as i know), but works fine after restarting python3-validity service

If enable open-fprintd-resume and open-fprintd-suspend, then when trying to use reader it stucks with no response, also there is an error log for open-fprintd-resume service:

× 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-02-09 11:27:21 MSK; 13s ago
    Process: 2793 ExecStart=/usr/lib/open-fprintd/resume.py (code=exited, status=1/FAILURE)
   Main PID: 2793 (code=exited, status=1/FAILURE)
        CPU: 43ms

Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write
Feb 09 11:27:21 t480s resume.py[2793]:     return self.__write(self.lib.libusb_bulk_transfer,
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in __write
Feb 09 11:27:21 t480s resume.py[2793]:     _check(retval)
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check
Feb 09 11:27:21 t480s resume.py[2793]:     raise USBError(_strerror(ret), ret, _libusb_errno[ret])
Feb 09 11:27:21 t480s resume.py[2793]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'.
Feb 09 11:27:21 t480s systemd[1]: Failed to start Restart devices after resume.

[saunite]

Have an issue after suspend on t480s: if open-fprintd-resume and open-fprintd-suspend disabled then there is [Errno 19] No such device (it may have been disconnected) error when trying to use reader (message comes from /usr/lib/open-fprintd/resume.py as i know), but works fine after restarting python3-validity service

If enable open-fprintd-resume and open-fprintd-suspend, then when trying to use reader it stucks with no response, also there is an error log for open-fprintd-resume service:

× 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-02-09 11:27:21 MSK; 13s ago
    Process: 2793 ExecStart=/usr/lib/open-fprintd/resume.py (code=exited, status=1/FAILURE)
   Main PID: 2793 (code=exited, status=1/FAILURE)
        CPU: 43ms

Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write
Feb 09 11:27:21 t480s resume.py[2793]:     return self.__write(self.lib.libusb_bulk_transfer,
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in __write
Feb 09 11:27:21 t480s resume.py[2793]:     _check(retval)
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check
Feb 09 11:27:21 t480s resume.py[2793]:     raise USBError(_strerror(ret), ret, _libusb_errno[ret])
Feb 09 11:27:21 t480s resume.py[2793]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'.
Feb 09 11:27:21 t480s systemd[1]: Failed to start Restart devices after resume.

Hi,

I had the exact same problem on Fedora 36 (was working fine on 35), I managed to fix it changing "/usr/lib/systemd/system/open-fprintd-resume.service" to this:

[Unit]
Description=Restart devices after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=oneshot
#ExecStart=/usr/lib/open-fprintd/resume.py
ExecStart=systemctl restart open-fprintd.service python3-validity.service

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Here's the thread where I found the solution: #106

[rc345ct243tc]

I'm running in to the same issue after upgrading to Fedora 36. I was wondering if there is a plan to release a more permanent fix to this?

[Fuseteam]

Hi Peter, I also experineced the suspend issue on my X1's 009a sensor when I try using uunicorn's open-fprintd a while ago, so I forked marco's libfprint-tod-vfs0090 driver in my repo ( https://gitlab.com/bingch/libfprint-tod-vfs0090), made some changes so it works for 009a too. As this setup uses the upstream fprintd instead, suspend works well, it might work for your 0097 sensor too. Note you still need to use uunicorn's python-validity package to initialize and enroll fingerprint
…
On Thu, 2020-09-10 at 01:00 -0700, Peter Babič wrote: Hello, great work! I am very thankful for this project. However, this thread is quite long and is discussing multiple issues. Could there please be a separate issue thread to just track the "make it work after suspend" status, please? I do have a 0097 sensor, yet the information about suspend issue spread here in the thread for 009a and there are also multiple mentions in the AUR. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

just wondering, how upstreamable is your fork? ithe original reason for open-fprintd was because allowing integration of python-valitity would make it easier to use proprietary drivers iirc

[4rc0s]

I'm struggling to keep my T480S 009a sensor working properly after suspend. It sometimes works and other times fails to respond at all after waking from sleep. I have enabled sudo systemctl enable open-fprintd-resume open-fprintd-suspend

Is there a recommended approach?

[latenightdef]

Have an issue after suspend on t480s: if open-fprintd-resume and open-fprintd-suspend disabled then there is [Errno 19] No such device (it may have been disconnected) error when trying to use reader (message comes from /usr/lib/open-fprintd/resume.py as i know), but works fine after restarting python3-validity service
If enable open-fprintd-resume and open-fprintd-suspend, then when trying to use reader it stucks with no response, also there is an error log for open-fprintd-resume service:

× 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-02-09 11:27:21 MSK; 13s ago
    Process: 2793 ExecStart=/usr/lib/open-fprintd/resume.py (code=exited, status=1/FAILURE)
   Main PID: 2793 (code=exited, status=1/FAILURE)
        CPU: 43ms

Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write
Feb 09 11:27:21 t480s resume.py[2793]:     return self.__write(self.lib.libusb_bulk_transfer,
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in __write
Feb 09 11:27:21 t480s resume.py[2793]:     _check(retval)
Feb 09 11:27:21 t480s resume.py[2793]:   File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check
Feb 09 11:27:21 t480s resume.py[2793]:     raise USBError(_strerror(ret), ret, _libusb_errno[ret])
Feb 09 11:27:21 t480s resume.py[2793]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Main process exited, code=exited, status=1/FAILURE
Feb 09 11:27:21 t480s systemd[1]: open-fprintd-resume.service: Failed with result 'exit-code'.
Feb 09 11:27:21 t480s systemd[1]: Failed to start Restart devices after resume.

Hi,

I had the exact same problem on Fedora 36 (was working fine on 35), I managed to fix it changing "/usr/lib/systemd/system/open-fprintd-resume.service" to this:

[Unit]
Description=Restart devices after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=oneshot
#ExecStart=/usr/lib/open-fprintd/resume.py
ExecStart=systemctl restart open-fprintd.service python3-validity.service

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Here's the thread where I found the solution: #106

Have you tried this one yet? Worked for me on Fedora 37 on a T480s.

[4rc0s]

I'm using Mint 21.1 (Vera), so Ubuntu 22.04 based. I found that file in /lib/systemd/system and made the changes. I'll restart and test.

[timrosu]

I'm on Arch (kernel 6.7.5-arch1-1). When my T480 wakes from sleep, I need to wait about 10 seconds if I want to unlock it with a fingerprint. Sometimes it just fails to activate sensor on the first try and it works second time. I don't know what to do anymore. I've reset the fp reader a few times and it didn't help. I have open-fprintd-resume and open-fprintd-suspend enabled.