Add USB capture replay test using umockdev, generated with
create-driver-test.py on a Fujitsu notebook with NB-2033-U reader.
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.com>
Add a new driver for the NEXT Biometrics NB-2033-U fingerprint reader
(USB ID 298d:2033). The NB-2033-U uses the same sensor die as the
NB-1010-U/NB-2020-U (256x180 @ 385 DPI) but a different USB protocol.
Protocol reverse-engineered from USB captures (usbmon) on Linux.
No proprietary code was used.
Key protocol differences from NB-1010-U:
- Bulk IN on EP 0x81 (not EP 0x83)
- TLV command framing: [CMD][0x00][LEN_LO][LEN_HI][PAYLOAD]
- Enhanced finger detection requires two 0x0D config commands before 0x38
- Image transfer: 180 individual rows of 268 bytes (12 hdr + 256 pixels)
- Init command (0x07) must be sent twice per detection cycle
Tested with fprintd-enroll and fprintd-verify on a Fujitsu notebook with
integrated NB-2033-U reader: enrollment (5/5 stages), verification
(correct finger matches, wrong finger rejected).
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.com>
Add USB PID 0x2020 (NB-2020-U) to the nb1010 driver's id_table.
The NB-2020-U is an embedded variant of the NB-1010-U using an
identical sensor die (confirmed by independent teardown reports from
System Plus Consulting/Yole Group). USB endpoint layout, command
protocol and image format are identical between both devices.
Tested on a Fujitsu notebook with integrated NB-2020-U reader
(USB ID 298d:2020): device enumeration, finger detection polling
and image capture all work correctly with the existing nb1010
driver code.
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.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
