Opening this as a heads-up for anyone hitting the same device, and with a working fork in case it is useful.
I have a 27c6:5110 whose silicon revision is not handled by the current drivers. driver_51x7.py aborts at the chip id check:
| Property |
Expected |
This device |
| chip id |
a2042500 |
a2052200 |
| OTP length |
64 bytes |
32 bytes |
| reset number |
2048 / 1024 |
1024 |
| decrypted frame |
10573 bytes |
22189 bytes |
| geometry |
80x88 |
132x112 |
Three things had to change to get enrolment and verification working:
The hardware finger-detect never fires. The sensor ACKs MCU_SWITCH_TO_FDT_DOWN and then stays silent indefinitely, with the 51x0 table, the 51x7 table, or a deliberately extreme threshold. The OTP is genuinely 32 bytes (the reply itself declares length 33), so bytes 42 and 46-49 — the AFE trim and detector offset — are simply absent. Borrowing the 51x7 register constants makes it worse: mean frame level drops from ~2230 to 0.7 out of 4095 and stays there until the USB device is power-cycled.
Since frames can be captured without the detector, I replaced it with software detection: stream frames, compare the mean against an adapting baseline. Idle drifts 0.0-0.1 %, a finger drops it 25-35 %.
Geometry is 132x112, not 88x168. Both are 14784 pixels so nothing crashes, but the wrong row width shears the ridges into diagonal striping — enrolment completes and verification never matches. If anyone needs to determine this for another part: decode the frame and correlate adjacent rows for each candidate width; the correct one stands out clearly (0.574 at 132 here, 0.33-0.40 elsewhere).
The image arrives as one TLS record of 22213 bytes, above the 16384 maximum. OpenSSL rejects it with encrypted length too long and drops the session, which is also why piping frames through openssl s_server fails on this device. It has to be decrypted manually; note that the sequence number should be taken from the explicit nonce rather than tracked, or it breaks whenever the device re-activates and numbering restarts at 1.
Fork with the patch and a fuller write-up: https://github.com/HRYNdev/libfprint-goodix-a2052200
Happy to run any further dumps on this device if that helps identify the revision properly.
Opening this as a heads-up for anyone hitting the same device, and with a working fork in case it is useful.
I have a
27c6:5110whose silicon revision is not handled by the current drivers.driver_51x7.pyaborts at the chip id check:a2042500a2052200Three things had to change to get enrolment and verification working:
The hardware finger-detect never fires. The sensor ACKs
MCU_SWITCH_TO_FDT_DOWNand then stays silent indefinitely, with the 51x0 table, the 51x7 table, or a deliberately extreme threshold. The OTP is genuinely 32 bytes (the reply itself declares length 33), so bytes 42 and 46-49 — the AFE trim and detector offset — are simply absent. Borrowing the 51x7 register constants makes it worse: mean frame level drops from ~2230 to 0.7 out of 4095 and stays there until the USB device is power-cycled.Since frames can be captured without the detector, I replaced it with software detection: stream frames, compare the mean against an adapting baseline. Idle drifts 0.0-0.1 %, a finger drops it 25-35 %.
Geometry is 132x112, not 88x168. Both are 14784 pixels so nothing crashes, but the wrong row width shears the ridges into diagonal striping — enrolment completes and verification never matches. If anyone needs to determine this for another part: decode the frame and correlate adjacent rows for each candidate width; the correct one stands out clearly (0.574 at 132 here, 0.33-0.40 elsewhere).
The image arrives as one TLS record of 22213 bytes, above the 16384 maximum. OpenSSL rejects it with
encrypted length too longand drops the session, which is also why piping frames throughopenssl s_serverfails on this device. It has to be decrypted manually; note that the sequence number should be taken from the explicit nonce rather than tracked, or it breaks whenever the device re-activates and numbering restarts at 1.Fork with the patch and a fuller write-up: https://github.com/HRYNdev/libfprint-goodix-a2052200
Happy to run any further dumps on this device if that helps identify the revision properly.