scan-build flags ordered->next as a possible null deref because it
cannot correlate the GSList length with frames_captured. The
frames_captured >= MIN_FRAMES guard upstream of the head drop makes
the deref safe in practice, but adding an explicit ordered &&
ordered->next check silences the analyzer without changing behavior.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds an image driver for the Samsung USB fingerprint sensor
(04e8:7305) shipped in the Samsung Notebook 7 Spin
(NP730QAA-K02US). The protocol was reverse-engineered from
USB captures of the Windows vendor driver.
The sensor is a 56x192 8-bit grayscale area sensor. Capture
requires a 4-trigger sequence (3 pre-capture strip reads plus
one full-frame read) and a vendor control-transfer bracket
(heartbeat / response-length prime / wait-ready doorbell on
EP0) around every bulk transfer.
The sensor is physically a press sensor but is declared as
FP_SCAN_TYPE_SWIPE and assembled from multiple frames via
fpi_assemble_frames(), because NBIS's minutia extractor needs
more ridge area than a single 56x192 frame provides. An
inline comment near ASSEMBLE_STRIDE explains the rationale
and references drivers/elan.c for precedent.
A umockdev-based capture test is included. Protocol
documentation and development history:
https://github.com/jwhall/samsung7305
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
