[bug] auto-lock time-out don't work properly [released]

@spiiroin thank you very much for your intervention.
yes you're right, i forgot to mention some details.
I'll update the thread because i have, new info in my search of good reproducibility, and beg you to give a look again on it.
I noticed that is not that easy for a bug to reproduce. Since remark from poddl i noticed other things happened.

oh sorry for the half answer...
after rereading you , i understood the 2nd part of your answer.
I noticed it with the new jolla-store game machine vs machine.
But i'm pretty sure that was already the case with old sfos versions.
Because i remember that in many time i had the feeling that the lock-time was too short, but not short enough that i should more investigate on it.
With this game, i was surprised that the device was locked after finish to play with. This game crashs if we go on sfos home (is that an effect with the lock mechanism?).
But independently to play with this game, i took the Jolla-clock app to test the lock time. For example, set a timer of 7min with a lock-time of 10min. So that i could see, that the timer time is correct, but the lock-time not.
Most of the time i have always the apps "situation" and "battery log" from mrmoo. Both native app from jolla-store.

@spiiroin is it possible to see something in the os logs which could give interesting informations? Like Special events which comes regularly each x-time. With os time-stamping we could see maybe if the time get wider by some cases. (it's maybe a fantasy from me).
Would it be possible to know, on which kind of logs may we have access in our devices?

@cemoi71: Because mce is source of some inputs (activity, display state, ..) for device lock and also listens to device lock state changes -> by adjusting mce verbosity most of the triggers / state changes should end up in journal.

This should be enough (and is not persistent, back to normal verbosity on the next reboot / mce restart):

mcetool --set-verbosity=notice

Here is relevant parts picked from "leave it idle and let it dim, blank and lock device" sequence:

13:52:50 tklock.c: tklock_datapipe_device_lock_state_cb(): device_lock_state = locked -> unlocked
^ double power key wakeup + lock code entered -> unlocked
13:52:50 tklock.c: tklock_dbus_systemui_callback_cb(): tklock callback value: 1, from name=:1.48 pid=1149 cmd=/usr/bin/lipstick -plugin evdevtouch:/d
13:52:50 tklock.c: tklock_dbus_send_tklock_mode(): send tklock mode signal: unlocked
^ exit from lockscreen
13:53:20 modules/display.c: mdy_display_state_enter(): current display state = DIM
^ default display dimming delay = 30 s
13:53:22 modules/inactivity.c: mia_dbus_send_inactivity_state(): Sending inactivity signal: inactive
^ inactivity state declared
13:53:23 modules/display.c: mdy_display_state_leave(): current display state = POWER_DOWN
13:53:24 modules/display.c: mdy_display_state_enter(): current display state = OFF
^ display is blanked
13:53:53 tklock.c: tklock_dbus_send_tklock_mode(): send tklock mode signal: locked
^ 30 sec grace period over, lockscreen activated
13:58:27 tklock.c: tklock_datapipe_device_lock_state_cb(): device_lock_state = unlocked -> locked
^ inactivity + 5 minute device lock delay +  up to heartbeat (12 secs) -> device is locked

on which basis is this "inactivity" sent just taping and swish? how could we explain that during the game "machines vs machines" the device will be locked in background, while strongly active with taping and swishing?