Fingerprint identify loop leading to loss of CPU sleep

[rinigus]

In SFOS 4.1.0.23, fingerprint sometimes fails to identify, especially after longer idle phone time. In addition, fingerprint identification can be requested by SFOS in a loop which can lead to inability to enter CPU sleep state for longer time (like 40mins). Logs are very similar in the both cases

May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: int FPDCommunity::Identify(const QDBusMessage&) ":1.1"
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::setState(FPDCommunity::State) FPDCommunity::State(FPSTATE_IDENTIFYING)
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void AndroidFP::authenticate()
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: static void AndroidFP::error_cb(uint64_t, UHardwareBiometryFingerprintError, int32_t, void*) 5 0
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::slot_failed(const QString&) "ERROR_CANCELED"
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::setState(FPDCommunity::State) FPDCommunity::State(FPSTATE_IDLE)
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: int FPDCommunity::Identify(const QDBusMessage&) ":1.1"
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::setState(FPDCommunity::State) FPDCommunity::State(FPSTATE_IDENTIFYING)
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void AndroidFP::authenticate()
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: static void AndroidFP::error_cb(uint64_t, UHardwareBiometryFingerprintError, int32_t, void*) 5 0
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::slot_failed(const QString&) "ERROR_CANCELED"
May 16 08:18:49 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::setState(FPDCommunity::State) FPDCommunity::State(FPSTATE_IDLE)
May 16 08:18:50 XperiaXZ2Compact sailfish-fpd-community[3404]: int FPDCommunity::Identify(const QDBusMessage&) ":1.1"
May 16 08:18:50 XperiaXZ2Compact sailfish-fpd-community[3404]: void FPDCommunity::setState(FPDCommunity::State) FPDCommunity::State(FPSTATE_IDENTIFYING)
May 16 08:18:50 XperiaXZ2Compact sailfish-fpd-community[3404]: void AndroidFP::authenticate()
...

[spiiroin]

That ":1.1" private client name is likely to be = mce -> points towards fp wakeup handling.

Getting such loop in case of errors is more or less expected. It should be throttled, but only to extent that a) cpu usage is limited b) the situation is expected to clear itself e.g. it is some temporary issue with sensor ownership between mce & device lock / similar.

To gauge whether it is indeed mce + fpwakeup, one could try disabling/enabling fp wakeup altogether (while the situation is on)
and/or adjusting throttling delays with mcetool(--set-fingerprint-wakeup-mode / --set-fingerprint-wakeup-throttle-delay options.

[Also, provided that the problem does not go away on mce restart, then running mce manually / adding -lmodules/fingerprint.c:* to mce.service Exec line and using journalctl -o short-precise might give more insight on timing etc]

One should perhaps device some give-up-after-n-tries logic in mce anyway, but it would be nice to know what the underlying problem is first as it could be some interoperability issue between mce and community fpd too.

[rinigus]

Let's start from the bottom - I don't expect community fpd to be incompatible in the sense that it is leading to such problem. It is pretty straightforward implementation and is driven by DBus requests. It just replies to all requests and have no extra penalties, throttling on its side.

As for the FP wakeup handling by mce, I wonder if it changed recently. On AOSP9 based port, I have

Fingerprint wakeup policy:           never

However here, for AOSP10, I have

Fingerprint wakeup policy:           always

To my understanding, on Tama, there is a wakeup handling on FP action provided by AOSP. For example, on AOSP9 (and expect same on AOSP10), while suspended, I can put finger on FP reader and will get in logcat

05-16 09:34:54.628  3638  4346 D FPC COMMON: Waking up from finger event
05-16 09:34:56.138  3638  4346 I FPC IMP : Gesture: Hold
05-16 09:34:56.314  3638  4346 D FPC COMMON: Waking up from finger event
05-16 09:34:56.844  3638  4346 D FPC COMMON: Waking up from finger event
05-16 09:34:59.913  3638  4346 I FPC IMP : Gesture: Finger gone

I wonder whether that causes the issue. I guess I should disable FP wakeup by MCE through overwriting
https://github.com/mer-hybris/droid-hal-configs/blob/master/sparse-10/etc/mce/60-fingerprint-sensor.conf

Any tips on what should I set as a mode? =0? As this config is pulled from generic sparse-10, I guess I need to get overriding file with the name like

/etc/mce/90-fingerprint-sensor-tama.conf

[rinigus]

PS: Adding file

/etc/mce/90-fingerprint-sensor-tama.conf

with /system/osso/dsm/fingerprint/mode=0 looks to disable FP wakeup by MCE. I hope it is correct and let's see if it helps

[spiiroin]

with /system/osso/dsm/fingerprint/mode=0 looks to disable FP wakeup by MCE. I hope it is correct and let's see if it helps

That is correct.

... in general it goes something like:

# grab current state of mce (delta to default) settings
cp /var/lib/mce/builtin-gconf.values prev
# modify something
mcetool --set-fingerprint-wakeup-mode=never
# compare to saved state
diff prev /var/lib/mce/builtin-gconf.values
+/system/osso/dsm/fingerprint/mode=0

[spiiroin]

Regarding mce fp-wakeup feature: For correct behavior it requires that underlying hw and android sw can keep the sensor powered on and in "authenticate" mode even if the device suspends. So that putting finger on sensor -> can wake device from suspend -> auth operation continues and successful match is communicated normally -> mce will wake up display. If some portion of this chain is not working as expected, it might be better to keep the feature disabled to avoid non-deterministic behavior / other kinds of hiccups. For example (IIRC etc) XperiaX does not wake up from finger-on-sensor -> auth does work if device happens to be out of suspend for other reasons -> sometimes it works, sometimes it does not -> not good ux-wise -> feature is disabled.

[rinigus]

Disabling FP wakeup fixed the issue (sailfishos-sony-tama/droid-config-sony-tama-pie@dd85d46)

@spiiroin, reading your description it makes sense that Tama port enters such loop. In Tama, FP reader is on the back of the device. So, while lying on the back, it maybe is triggering FP reader and failing shortly in some conditions. For us, the wakeup feature is probably not needed anyway as we have pickup sensor. Sensor is hooked to wakeup the device when it is picked up and it will be ready to accept the fingerprint anyway.

So, over here, I can close the issue by just disabling it.

Thank you very much for your help.

CC @piggz - see background on FP wakeup in SFOS.