We have moved to a new Sailfish OS Forum. Please start new discussions there.

Bug: auto sleep mode stop working

asked 2014-01-03 17:57:01 +0300

Vivien gravatar image

updated 2014-11-26 12:48:13 +0300

jiit gravatar image

Sometime, the auto sleep mode stop working: anywhere I am, except in the lock screen, the Jolla won't turn into sleep mode after the configured delay. This behavior seems to happen randomly. To make it work again, I must reboot the Jolla.

Edit: Just bringing this old bug up, as some new customers in India seems to be experiencing it too

edit retag flag offensive close delete


I have noticed this bug as well.

mato ( 2014-01-03 18:36:44 +0300 )edit

Happy to see that I'm not the only one.

Vivien ( 2014-01-03 18:39:01 +0300 )edit

Same thing here.

pelsepupi ( 2014-01-03 19:35:59 +0300 )edit

Have the same sometimes.

Slawek ( 2014-01-03 22:03:19 +0300 )edit

same thing here. After some delay the keyboard for the lock code appears but the screen don't go into sleep mode. If I go on the Home screen, the screen goes black after 10/15 secondes

When this happens, journalctl gives me a lot of those lines : Jan 12 20:13:34 localhost mission-control-5[1001]: GLIB CRITICAL ** tp-glib - tp_cli_connection_interface_power_saving_call_set_power_saving: assertion TP_IS _CONNECTION (proxy)' failed Jan 12 20:13:34 localhost dbus-daemon[910]: (process:1001): tp-glib-CRITICAL **: tp_cli_connection_interface_power_saving_call_set_power_saving: assertionTP _IS_CONNECTION (proxy)' failed

kael ( 2014-01-12 11:10:00 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2014-09-30 11:45:57 +0300

spiiroin gravatar image

updated 2017-02-16 13:49:15 +0300

The original issue was dup of https://together.jolla.com/question/13191/display-doesnt-turn-off-automatically/ - i.e. in early releases it was very likely that lipstick and mce got out of sync regarding the lockscreen-is-active status (IIRC things happening during incoming call caused most of the problems) -> this lead in to too short/long blanking timers to be used, or in some cases no blanking at all.

Most of these issues were fixed around Jan/Feb 2014.

@simo: Do you have any details on problems new users are facing?


Another possible source of confusion dawned on me in the depths of comment chain below (thanks to @Tanghus): There is "adaptive dimming" feature that is enabled by default -> The display blanking timeout varies depending on how device is used -> see https://together.jolla.com/question/121098/touching-the-screen-when-dimming-temporarily-raises-display-timeout-to-the-higher-level/ for details.

edit flag offensive delete publish link more


@spiiroin The one you linked might be closed as dub? And sry, but no more info on my knowledge - it's even possible that the problem is encountered with an outdated system version.

simo ( 2014-09-30 12:15:16 +0300 )edit

I still get this issue with 1.1.4.x.

For instance, this morning after my alarm went off and I silenced it, the screen remained on at the lock screen until I manually turned it off over a minute later. The auto-off is set to 30 seconds.

Turning the screen on now gives the same issue - still on over a minute later. I have seen it turn off sometimes though - though that could be because of the proximity sensor?

EDIT: I seem to have fixed it with mcetool. The Blank Inhibit option was set to "stay-on", so I changed it to "stay-on-with-charger". After unplugging, the display turned off after the relevant no. of seconds.

skanky ( 2015-06-10 11:45:04 +0300 )edit

@skanky: If the display comes up due to alarm, it should also turn off after alarm - even if stay-on inhibit mode is used. However there have been some subtle problems that might have caused it to misbehave.

spiiroin ( 2015-06-14 10:16:57 +0300 )edit

@spiirion many thanks for that. The alarm issue is the only one remaining now. Any hints on causes or fixes?

skanky ( 2015-06-14 21:38:10 +0300 )edit

@skanky: Issues with lockscreen/suspend/resume/timing caused display state restore to be canceled. In normal use it meant the display could stay on (few seconds) too long after alarm. While I've not explicitly tested this variant problem with 1.1.4.x release, logically stay-on inhibit mode just makes the "too-long" become "forever". Should be fixed in >= 1.1.6.x.

spiiroin ( 2015-06-15 10:28:12 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2014-01-03 17:57:01 +0300

Seen: 600 times

Last updated: Feb 16 '17