Skip to content

Validity VFS5011 (138a:0011) not detected by python3-validity - "No matching devices found" #248

@life-is-jesus

Description

@life-is-jesus

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions