Implement the firmware extension (fwext) upload module for
Validity/Synaptics VCSFW sensors. When the sensor reports no
firmware loaded (GET_FW_INFO returns status 0xB004), the driver
uploads the .xpfwext firmware file using the following sequence:
1. WRITE_HW_REG32 (0x08) to prepare hardware register
2. READ_HW_REG32 (0x07) to verify register state
3. Load .xpfwext file from filesystem search paths
4. For each 4KB chunk:
a. Send db_write_enable blob (encrypted auth token)
b. WRITE_FLASH (0x41) with chunk payload
c. CLEANUP (0x1A) to commit chunk
5. WRITE_FW_SIG (0x42) to upload RSA signature
6. GET_FW_INFO (0x43) to verify successful upload
7. REBOOT (0x05 0x02 0x00) to activate new firmware
Architecture: Uses the NULL-callback subsm pattern where SEND
states call vcsfw_cmd_send(self, ssm, cmd, len, NULL) and RECV
states read self->cmd_response_status/data directly. This avoids
the double-advance bug with fpi_ssm_start_subsm auto-advancing
the parent.
New files:
- validity_fwext.h: Structures, SSM state enum, API declarations
- validity_fwext.c: Upload SSM, file parser, command builders
- validity_blob_dbe_009a.inc: db_write_enable blob for 06cb:009a
- test-validity-fwext.c: 19 unit tests covering all pure functions
Modified files:
- validity.h: Add cmd_response_status field to FpiDeviceValidity
- validity.c: Add OPEN_UPLOAD_FWEXT state to open sequence
- vcsfw_protocol.c: Save status in cmd_receive_cb for RECV states
- meson.build: Add validity_fwext.c to driver sources
Test results: 34 OK, 0 Fail, 2 Skipped
Add a new "validity" driver for Validity/Synaptics fingerprint sensors
that use the VCSFW protocol (as opposed to BMKT). This is iteration 1
of a multi-phase effort to bring native libfprint support to these
widely-deployed sensors found in ThinkPad T480/T480s/T580/X1 Carbon
Gen6 and many other laptops.
This initial iteration implements:
- VCSFW command/response transport layer over USB bulk endpoints
- GET_VERSION command parsing (firmware version, product ID, build)
- Synchronous probe and async open/close state machines
- Stub implementations for enroll/verify/identify (return NOT_SUPPORTED)
- umockdev replay test with real hardware capture
Supported USB IDs (VCSFW protocol):
- 138a:0090 (Validity VFS7500)
- 138a:0097 (Validity VFS5011)
- 06cb:009a (Synaptics Metallica MIS Touch)
- 138a:009d (Validity VFS7552)
These were previously (incorrectly) claimed by the synaptics driver
which uses the BMKT protocol.
Re-record the umockdev USB capture to include the new
GOODIX_VERIFY_WAIT_FINGER_UP state's USB exchanges during
verify and identify operations.
Captured on a Goodix MOC sensor (27c6:609c, Framework Laptop 13)
with FP_DEVICE_EMULATION=1 as required by the test framework.
The goodixmoc driver's verify state machine was missing a
WAIT_FINGER_UP state between IDENTIFY and PWR_BTN_SHIELD_OFF.
After the sensor reported a match/no-match result, the driver
immediately completed the verify operation without waiting for
the finger to be lifted from the sensor.
This caused problems when fprintd retried verification after a
no-match: the finger was still on the sensor, so the same
(wrong) finger was scanned again instantly. On fast match-on-chip
readers, all retry attempts could be exhausted in under a second,
giving the user no time to reposition their finger.
Add GOODIX_VERIFY_WAIT_FINGER_UP to the verify state machine,
mirroring the existing GOODIX_ENROLL_WAIT_FINGER_UP in the
enroll flow. The new state sends MOC_CMD0_FINGER_MODE /
MOC_CMD1_SET_FINGER_UP to the sensor and waits for the finger
to be removed before advancing to PWR_BTN_SHIELD_OFF.
The callback handles the same cases as the enroll equivalent:
- Timeout (5s): retry the finger-up wait
- Protocol error: fail the SSM
- Success: clear FINGER_STATUS_PRESENT and advance
Link: https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/209
This FPreader was found on Minisforum X1 Pro MiniPC, and it is
listed by lsusb as "Generic Realtek USB2.0 Finger Print Bridge".
Though the VID is not the same as the well-known "0bda", we can
confirm it's from Realtek by analyzing Windows version driver.
Signed-off-by: Ryan Wong <colorfulshark@gmail.com>
If the button shield command cannot be executed due to an underlying
error then resp is NULL. Avoid the crash by adding the appropriate
check.
Closes: #694
