The funny thing is, I have compared the old/new code quite a bit, and the control flow appears identical. And it does work fine the first time it runs, which makes things even weirder.
The interesting this is that
(fprintd:1619448): libfprint-upekts-CRITICAL **: 21:59:54.929: fingerprint data too short (1 bytes)
means that the driver thought it was getting the final enrolled print (only happens at the end). But it happens too early and there is no print data attached.
I am not really surprised about the different errors. There is a double free currently for the returned error (already have a patch see https:/ /gitlab. freedesktop. org/libfprint/ libfprint/ -/merge_ requests/ 143 on top of the earlier https:/ /gitlab. freedesktop. org/libfprint/ libfprint/ -/merge_ requests/ 142).
The funny thing is, I have compared the old/new code quite a bit, and the control flow appears identical. And it does work fine the first time it runs, which makes things even weirder.
The interesting this is that
(fprintd:1619448): libfprint- upekts- CRITICAL **: 21:59:54.929: fingerprint data too short (1 bytes)
means that the driver thought it was getting the final enrolled print (only happens at the end). But it happens too early and there is no print data attached.