Ask / Submit

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

Tracked by Jolla (In release)

asked 2016-11-17 12:08:28 +0300

cemoi71 gravatar image

updated 2017-04-21 19:09:21 +0300

Hello all,

it seems that the time-out for locking the device automatically, not happened correctly like it is defined in the device-lock options.
On my device, if I set-up this time to 5 minutes, i observed that my device is locked between 3min and 3"30.
Time-out set-up to 10min, then the device is locked between 6min and 7min.
Time-out set-up to 30min, then the device is locked before 20min.
It locks itself too early.

Actually I don't know if it happened the same for the 60min time-outs.
That's too long for me, i don't know how i could observe the event exactly when it engage itself.
The best would be to observe a kind of dedicated event message in a terminal, through ssh (dev-mode).

Furthermore i noticed that, the lockscreen activate by itself automatically during the use of some applications.
For example with the native game "machines vs machine", after i finish to play with it, i come directly to the lockscreen. I'll try to notice with which other app i have the same issue.

Edit 21.11.2016:
Last weekend happened some further weird things.
The device locked itself during a skype (android) call.
One Time it locked itself directly after an unlock action. And as poddl remarked, i rebooted my device too. After it, it didn't spare itself before 4min for a 5min lock-time.

Edit 23.11.2016:
Seems for me that there is at last 2 kinds of bug for the lock-screen:
- One with the time-out drift (firstly noticed and reported here).
- The other one would be the automatic lock in background of an app (afterwards noticed, and reported here too).

Myself i have a JP1 with sfos
Offset seems to be observed on a jolla-C to.

Edit 21.04.2017:
New observation with sfos
Shortly i noticed that after the update to the last release, some days after it happens that the device lock itself after any calls. If the lock option is set to lock automatically without delay.
I report it in an old thread that i found here.
But was surprised that the issue disappear after restarting the lipstick interface.
Is that the same bug, or is to be handled separately?

Has anybody the same issues? which device do you have and with which OS Version?
And what are the apps that you commonly use , which may take a lot's of OS resources (like a game or communication, video, compression tool).

Have good continuation.


edit retag flag offensive close delete



Yes, I have 60 minutes and some times it is locked after about 30 minutes After reboot it feels again like 60 minutes.

poddl ( 2016-11-17 22:47:52 +0300 )edit

Really? i didn't try it after a reboot. That's a little bit strange what you report...

cemoi71 ( 2016-11-17 23:19:28 +0300 )edit

@poddl may i ask you which device do you have, which present the same problem?

cemoi71 ( 2016-11-21 14:13:36 +0300 )edit

@cemoi71 Jolla-C, I did never count it, and I do not know the event who trigger this problem, but after a few days running, the time gets wrong.

poddl ( 2016-11-21 16:35:25 +0300 )edit

@poddl quite interesting. approximatively how many days happen until you remark it goes wrong?
a week? an half month? a month?
Actually i don't know for me, and i try to determine it. That's why i ask you if you know it, for having an idea how long it could be.
Regarding the question of spiiroin here under, may i ask you which typ of app do you have 24h/24h active on your phone?

cemoi71 ( 2016-11-21 16:58:33 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2016-11-21 11:43:35 +0300

spiiroin gravatar image

updated 2016-11-23 16:18:53 +0300

I created internal ticket for this.

For attemps to reproduce the issue it would be helpful to know what device you are using and what if anything you were doing while waiting for the device lock to trigger (watching video, just let the device lie in peace, something else).


I did some tracing. Looks like a bug got introduced some time ago that effectively stopped the device lock code from registering user activity -> it basically locked after device lock delay no matter what else was done.

edit flag offensive delete publish link more


@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.

cemoi71 ( 2016-11-21 14:03:31 +0300 )edit

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.

cemoi71 ( 2016-11-21 14:30:23 +0300 )edit

@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 ( 2016-11-21 14:36:19 +0300 )edit

@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
spiiroin ( 2016-11-23 14:16:51 +0300 )edit

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?

cemoi71 ( 2016-11-23 16:05:04 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2016-11-17 12:08:28 +0300

Seen: 343 times

Last updated: Apr 21