-
Notifications
You must be signed in to change notification settings - Fork 95
Validity VFS5011 (138a:0011) not detected by python3-validity - "No matching devices found" #248
Description
Title: Validity VFS5011 (138a:0011) not detected by python3-validity - "No matching devices found"
Body:
Hello,
I am trying to get my fingerprint reader working on Linux, but the python3-validity service fails to detect it. The device works perfectly on Windows, so the hardware is functional.
Hardware Details:
Fingerprint Reader: Validity Sensors, Inc. VFS5011 Fingerprint Reader
USB ID: 138a:0011
Laptop Model: [Please fill in your laptop model here, e.g., Dell Vostro 3550]
lsusb output:
text
Bus 001 Device 006: ID 138a:0011 Validity Sensors, Inc. VFS5011 Fingerprint Reader
Linux Distribution: Zorin OS 18 (based on Ubuntu 24.04 Noble)
Problem Description:
The python3-validity service fails to start because it cannot find the device. The service log shows:
text
Exception: No matching devices found
I have confirmed that the device is accessible to userspace:
Correct udev rule is in place (/etc/udev/rules.d/99-validity.rules) with MODE="0660", GROUP="plugdev".
My user is in the plugdev group.
Device permissions are correct (crw-rw---- 1 root plugdev).
A simple pyusb script can find and interact with the device at 138a:0011.
Attempts to Switch to Bootloader Mode:
Based on the driver's logic, I suspect the device needs to be switched from application mode (0x0011) to bootloader mode (0x0010) for firmware upload. I attempted to send a control transfer with bRequest=0x0c, which is a common command for Validity sensors. The command resulted in a [Errno 32] Pipe error, which often indicates a device reset, but the device did not reappear with the new ID (138a:0010). It remained at 0011.
Here is the Python code used and the output:
python
import usb.core
dev = usb.core.find(idVendor=0x138a, idProduct=0x0011)
dev.ctrl_transfer(0x40, 0x0c, 0, 0, 0)
Output:
text
usb.core.USBError: [Errno 32] Pipe error
After this command and waiting for 10 seconds, lsusb continued to show the device as 138a:0011. No change occurred.
Request:
Could you please advise if there is a known, different control sequence to switch the 138a:0011 model into bootloader mode? Alternatively, is this specific device ID simply unsupported by the current driver? I can provide any further logs or testing if needed.
Thank you for your work on this project.