Bug 304877

Summary: None of the powersaving settings appear to have influence
Product: [Unmaintained] Active Reporter: Yannick Kiekens <yannickkiekens>
Component: GeneralAssignee: active
Status: RESOLVED FIXED    
Severity: critical CC: oliver.henshaw, sebas, wolfgang.romey
Priority: NOR    
Version: Master   
Target Milestone: unscheduled   
Platform: Meego/Harmattan   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Yannick Kiekens 2012-08-09 18:46:58 UTC
image used: basyskom-plasma-active-archos-gen9-omapfb-tablet-mer-testing-120805-1829.tar.bz2

After a fresh install:
* wait 5 minutes

Notice:
after 5 minutes, the lockscreen says the device will go to sleep, settings UI says it should just lock the screen

* Open the active settings program
* on the screen tab, disable all 3 switches
* close the settings program

Notice:
no change in the behaviour off the locking/power saving

* re-open the active settings program

Notice: 
2 off the 3 switches are re-enabled (turn off the screen & sleep)

* on the contour desktop, touch the battery icon
* touch the wrench icon in the popup

Notice:
None of the shown settings correspond to actual behaviour of the device

Reproducible: Always

Steps to Reproduce:
see details
Actual Results:  
see details
Comment 1 Thomas Pfeiffer 2012-08-10 15:12:31 UTC
I can confirm this on Wetab with plasma-active-wetab-exopc-tablet-mer-devel-120805-1940.iso.
Power management seems seriously messed up atm. We have two places with possibly conflicting settings, very strange defaults (sending a mobile device to sleep after 60 minutes? That doesn't make sense...) and none of them actually seem to work (my devices always suspends after five minutes as well, no matter what I set in both settings and even on AC power!)
We really need to get power management working, since it's really important on a mobile device.
Comment 2 Yannick Kiekens 2012-08-13 15:08:07 UTC
image used: basyskom-plasma-active-archos-gen9-omapfb-tablet-mer-testing-120812-1829.tar.bz2

only mentioning changed behaviour from the original test

* on the contour desktop
Battery icon is replaced by a red icon, indicating powersaving is not available

After a fresh install:
* wait 5 minutes

Notice:
Device shows lock screen instead of sleep timeout: ISSUE FIXED


NEW powermanagement issue:
* Disable the "Lock Screen" switch in active settings
* Reboot the device

Notice:
the device is stuck in a lockscreen loop
it appears as if disabling the switch sets the lock timeout to 0
Alse in this situation the lockscreen is only partially rendered


Reproducible: Always
Comment 3 Jean Cayron 2012-10-11 07:16:15 UTC
The fixed pushed in basyskom-plasma-active-archos-gen9-omapfb-tablet-mer-testing-release-rc3 works now on Archos G9. No more bug.

Great.
Comment 4 Jean Cayron 2012-10-11 08:26:29 UTC
Sorry, comment 3 is to delete. Not related to that bug. Sorry.
Comment 5 Oliver Henshaw 2013-01-26 15:05:11 UTC
See bug #310506 comment #3.
Comment 6 Wromey 2013-02-11 14:39:05 UTC
On the Wetab i have to disable power management, so i can work. 
After an update, screen brightness can go to 100%. After abotu 20 minutes, the screen gets darker and it is no longer possible to change the brightness.
Comment 7 Thomas Pfeiffer 2013-03-20 19:02:10 UTC
I can confirm that on my WeTab. After a while (far less than the 60 minutes shown in Settings), the screen actually goes off and won't turn on again unless you suspend an resume again.
Not sure if that's actually a PA problem or maybe a kernel problem.
Comment 8 Oliver Henshaw 2013-03-25 17:55:55 UTC
(In reply to comment #6)
> On the Wetab i have to disable power management, so i can work. 
> After an update, screen brightness can go to 100%. After abotu 20 minutes,
> the screen gets darker and it is no longer possible to change the brightness.
Brightness problems are at bug #312579

(In reply to comment #7)
> I can confirm that on my WeTab. After a while (far less than the 60 minutes
> shown in Settings), the screen actually goes off and won't turn on again
> unless you suspend an resume again.
> Not sure if that's actually a PA problem or maybe a kernel problem.
If you can get a konsole up can you tell me the result of 'xset -q' right now, and just after the screen turns off (do 'sleep XX; xset -q' with XX being whatever time it takes for the screen to turn off plus ten seconds).  Can you also get the result just before the screen turns off, for completeness?
Comment 9 Oliver Henshaw 2013-03-25 18:50:18 UTC
Git commit c07f1381545005d64e72e0699c9f0de37b492f62 by Oliver Henshaw.
Committed on 25/03/2013 at 17:34.
Pushed by oliverhenshaw into branch 'oliverhenshaw/power-timeouts'.

Suspend idle timeouts are stored in milliseconds

Was storing in centiseconds(?) and in seconds in one place.

Meant that suspend was activated much too soon. Suspend timeouts are
currently commented out due this problem but should work properly when
or if they are re-enabled.
Related: bug 310506

M  +7    -7    applications/settings/modules/powermanagement/contents/ui/Power.qml

http://commits.kde.org/plasma-mobile/c07f1381545005d64e72e0699c9f0de37b492f62
Comment 10 Oliver Henshaw 2013-03-25 18:50:18 UTC
Git commit 7c33ee0a6d2fa5b92431ad974e512f1b5d978366 by Oliver Henshaw.
Committed on 25/03/2013 at 17:21.
Pushed by oliverhenshaw into branch 'oliverhenshaw/power-timeouts'.

DPMS idle timeouts are stored in seconds

Meant that screen power-saving was probably never activated.
Related: bug 310506

M  +7    -7    applications/settings/modules/powermanagement/contents/ui/Power.qml

http://commits.kde.org/plasma-mobile/7c33ee0a6d2fa5b92431ad974e512f1b5d978366
Comment 11 Sebastian Kügler 2013-03-28 15:47:39 UTC
Confirmed working now.