asked 2014-01-03 17:57:01 +0300
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
answered 2014-09-30 11:45:57 +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?
EDIT:
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.
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: 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 )editAsked: 2014-01-03 17:57:01 +0300
Seen: 599 times
Last updated: Feb 16 '17
I have noticed this bug as well.
mato ( 2014-01-03 18:36:44 +0300 )editHappy to see that I'm not the only one.
Vivien ( 2014-01-03 18:39:01 +0300 )editSame thing here.
pelsepupi ( 2014-01-03 19:35:59 +0300 )editHave the same sometimes.
Slawek ( 2014-01-03 22:03:19 +0300 )editsame 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
kael ( 2014-01-12 11:10:00 +0300 )editTP_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