Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

power manager does not detect changes in power source #209

Closed
koshkamau opened this issue Dec 5, 2017 · 24 comments

Comments

Projects
None yet
10 participants
@koshkamau
Copy link

commented Dec 5, 2017

 * csd version ('dpkg --list | grep cinnamon-settings-daemon' in Mint/Ubuntu)
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
 * Graphics hardware *and* driver used
 * 32 or 64 bit

Linux mint cinnamon
17.2 x64, 18.2 x64, apparently 18.3 x64

Issue
Please, read more here: https://forums.linuxmint.com/viewtopic.php?f=49&t=202512&p=1053971#p1053971
I've written three posts there as "riseman"

Linux mint remembers its power source only upon boot up or entering-leaving power settings.
So, if laptop has booted on AC and then switched on BAT - it will still think that it is on AC.
This leads to problems when you have different power plans for different power sources.
In my case - my laptop won't suspend after electricity goes down, because it has "always on" plan for AC.
The problem can be partially avoided by using screensaver, but only partially and I don't need a screensaver.

Steps to reproduce

I have these settings:

Screensaver:

  • screen locker
  • lock the computer when put to sleen - ON
  • lock the computer when the screen turns off - OFF
  • lock the computer when inactive - NEVER

Power Management main:

  • Turn off screen when inactive for - NEVER(AC) / 10 min.(battery)
  • Suspend when inactive for - NEVER(AC) / 30 min.(battery)
  • When the lid closed - Do nothing in both cases

Power Management brightness:

  • On battery, dim screen when inactive - ON
  • Brightness level when inactive - 5%
  • Dim screen after inactive for - 2min.

I have a strange laptop's behavior with these settings.

Examples:

(1) the laptop is turned off and external power is not connected.
(2) Switching on, logging in, connecting external power.
(3) waiting
(4) Screen NOT dimming after 2 minutes of inactivity, but display is turned off after 10 minutes and suspend after 30 minutes.

(1) the laptop is turned off and external power is connected
(2) Switching on, logging in, disconnecting external power
(3) waiting
(4) Screen dimming after 2 minutes of inactivity, but display does not turned off after 10 minutes and laptop does not go to suspend.

Expected behaviour
in the first example on step (4) display shouldn't turn off and laptop shouldn't go to sleep because power source is AC

in the second example on step (4) screen should turn off after 10 minutes and the laptop should go to sleep after 30 minutes because power source is BATTERY.

Other information

I am sorry, I do not have any linux laptop now and I can't easily give you the version number of the daemon, drivers etc.
I personally faced this horrible problem in Linux mint 17.2 64bit and it still existed in 18.2 64 bit when I erased it from my laptop.
I didn't understand that I should write about this problem here, on github, so I wrote on linuxmint forum.
When linuxmint 18.3 beta appeared I asked a question on linuxmint blog about the status of this issue. Luckily, they noticed me and told that I should create an issue here. So, apparently, problem still exists in 18.3
I personally had this problem on Thinkpad x201 and Thinkpad x240. I also asked my friend to test this on his laptop (I don't know exact model but it is based on AMD APU) and he confirmed that the problem exists.
img-20171115-wa0002

@buck2202

This comment has been minimized.

Copy link

commented Feb 2, 2018

This has affected me also...my laptop would go to sleep automatically while plugged in, seemingly randomly. My settings were
screensaver: 15m
sleep (battery): 10m
sleep (ac): never

I've swapped the screensaver/sleep (battery) timeouts to test koshkamau's theory.

@koshkamau

This comment has been minimized.

Copy link
Author

commented Feb 2, 2018

The "theory" about significance of screensaver timeout is not mine. I luckily found it here

Screensaver is not a good way for me to solve this problem so I've made a simple daemon, which simulates access to power-settings menu (it writes to org.cinnamon.settings-daemon.plugins.power sleep-display-battery using gsettings) and it has solved this problem completely at least on Linux Mint 18.2

@buck2202

This comment has been minimized.

Copy link

commented Feb 4, 2018

Just following up. Setting a screensaver timeout that is less than either the A/C or battery sleep timeout has sidestepped the issue for me. I don't really want the screensaver, but this is the most attractive workaround to me.

cinnamon-settings-daemon 3.6.2+sylvia amd64
Release: 18.3
Codename: sylvia

@andreabellitto

This comment has been minimized.

Copy link

commented Feb 23, 2018

The screensaver one is a really bad workarround and even less solution...

@machineghost

This comment has been minimized.

Copy link

commented Feb 24, 2018

I disagree, it's totally a valid solution (thanks for posting it buck2202, and thanks koshkamau for helping me understand what was happening in the first place with your excellent blog post).

But with that said, it's clearly counter to the whole idea of screensavers and power management being separate if power management has a (SECRET) dependency on the screensaver. At the very least there should be a note on the power saving dialog ("only works when screensaver is enabled and triggers at least one minute before the power saving triggers") ... but obviously a better solution would be to remove the dependency.

@koshkamau

This comment has been minimized.

Copy link
Author

commented Feb 24, 2018

I beg to differ.
Screensaver solution has one significant flaw. The system checks power state only during the start of screensaver. If power state changed again after screensaver had been started - the system won't notice this.
So, the power plan which was actual on the moment of screensaver activation will be used when time comes to make decision - "to switch off or not to switch off" the whole system.

Actually, it's a poor design. It is so poor that I would cry every night if I did this.

@RecNes

This comment has been minimized.

Copy link

commented Mar 2, 2018

This problem is affecting my laptop too.

@xavierhd

This comment has been minimized.

Copy link

commented Apr 10, 2018

Just a heads-up, does the Kernel update 4.13.0-38.43 fix your problem? I know the change are Asus related, but maybe...
The changelog state :

  • [Asus UX360UA] battery status in unity-panel is not changing when battery is
    being charged (LP: #1661876) // AC adapter status not detected on Asus
    ZenBook UX410UAK (LP: #1745032)

    • ACPI / battery: Add quirk for Asus UX360UA and UX410UAK
  • ASUS UX305LA - Battery state not detected correctly (LP: #1482390)

    • ACPI / battery: Add quirk for Asus GL502VSK and UX305LA
@xavierhd

This comment has been minimized.

Copy link

commented Apr 10, 2018

I just tested 4.13.0-38.43 with the steps to reproduce, that was not it, the issue is still there.

@rschouwenburg

This comment has been minimized.

Copy link

commented Apr 10, 2018

The OP issue affects me too and the UX for me is very confusing. If the screensaver does not kick in before the suspend than my laptop does not suspend even when it's configured to do so after a timeout. If I switch from battery to AC power it still suspends even though it's configured to not suspend on AC power.

@clefebvre

This comment has been minimized.

Copy link
Member

commented May 31, 2018

Hi,

Can you provide the output the command below when on AC, and then after removing the plug and switching to battery?

upower --dump

This should show us whether upower reacts to the power source change.

I'd like to know also if the power applet reacts to that change.

@rschouwenburg

This comment has been minimized.

Copy link

commented May 31, 2018

Of course - thanks for looking into this. Here are mine:

upower-dump-on-ac.txt

upower-dump-on-bat.txt

The power applet changes its icon correctly.

@clefebvre

This comment has been minimized.

Copy link
Member

commented May 31, 2018

Cool, then it's probably on our side :)

Can you investigate the csd-power output? You can run it in verbose mode after killing it twice (cause csm restarts it once):

killall csd-power
killall csd-power
/usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-power --verbose

What does it output when switching power sources?

also, using d-feet, browse the session bus, go to org.cinnamon.SettingsDaemon.Power -> org/cinnamon/SettingsDaemon.Power, Methods, and double-click "GetDevices" and "GetPrimaryDevices" to run them (click the Execute button). This should list the power devices as seen by CSD and which one is considered the primary power device.

@rschouwenburg

This comment has been minimized.

Copy link

commented May 31, 2018

This is the output from csd-power - I started on AC and then to battery.

csd-power-verbose-output.txt

getDevices:
([('/org/freedesktop/UPower/devices/line_power_AC0', '', '', uint32 1, '. GThemedIcon ac-adapter-symbolic ac-adapter ', 0.0, uint32 0, uint64 0), ('/org/freedesktop/UPower/devices/battery_BAT0', 'Kollur', 'BASE-BAT', 2, '. GThemedIcon battery-full-symbolic gpm-battery-060 battery-full ', 62.0, 2, 3930)],)

getPrimaryDevices:
(('/org/freedesktop/UPower/devices/battery_BAT0', 'Kollur', 'BASE-BAT', uint32 2, '. GThemedIcon battery-full-symbolic gpm-battery-060 battery-full ', 61.0, uint32 2, uint64 11523),)

@clefebvre

This comment has been minimized.

Copy link
Member

commented May 31, 2018

Thanks @rschouwenburg this looks good.

I add this issue to the roadmap so we'll make sure to look into it prior to stable.

If you can test the BETA just to confirm this is still happening it would be great as well. We're expecting it to be out on the 4th of June.

@rschouwenburg

This comment has been minimized.

Copy link

commented Jun 6, 2018

I've tested the beta and the problem still exists for me.

@Zener131

This comment has been minimized.

Copy link

commented Jun 19, 2018

Good evening.
The following issue is the one annoying me. Despite the behavior is different, it clearly shows a bad dependency between the power management's triggers and the screensaver's cycle:
https://bugzilla.gnome.org/show_bug.cgi?id=793766
Hope it helps, Best regards.

@clefebvre

This comment has been minimized.

Copy link
Member

commented Jun 22, 2018

I can observe the issue and it looks like it's in CSD. Here's how to reproduce it easily:

Set CSD to turn off the screen never on AC and after 10 seconds on battery:

gsettings set org.cinnamon.settings-daemon.plugins.power sleep-display-ac 0
gsettings set org.cinnamon.settings-daemon.plugins.power sleep-display-battery 10

Kill CSD's power plugin:

killall csd-power
killall csd-power

Kill it two or three times in case CSM tries to respawn it.

Start CSD Power in verbose mode with the laptop on AC:

csd-power --verbose

  • Note that the screen doesn't turn off.
  • Remove the AC cord to put the laptop on battery.
  • Wait for the power applet to indicate the laptop is on battery (in accordance with upower --dump, this works well)
  • Note that the screen still doesn't turn off after 10 seconds or so (it's not supposed to be exactly 10 seconds)

Now, to confirm the other scenario.

  • Kill csd-power again
  • Put the laptop on battery mode (no power cord, with upower/applet aware that it's on battery mode)
  • Start csd-power
  • The screen is turned off after 10 sec or so... that's good
  • plug in the AC cord and wait for upower/applet to see the state change
  • Note that csd-power still turns the screen off

This confirms the observation made initially. It looks like csd-power reads the power state when it starts and doesn't update it then-after.

@koshkamau

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

it was interesting for me that CSD can be prompted to recheck power source by simply writing to, for example
gsettings set org.cinnamon.settings-daemon.plugins.power sleep-display-battery 250
At least it worked on 18.2 and 18.3
this is how I made a workaround for this bug. I used upower to trigger write procedures to gsettings.

@clefebvre

This comment has been minimized.

Copy link
Member

commented Jun 22, 2018

Yes, I added a bit of debug and it's basically down to the fact that we call idle_configure() at the start and when settings change. We should call it on upower state changes. Same with the dim configure method... the OP says dim is working, but looking at the code, I don't see how it would.

@koshkamau

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

I am the OP :) dim and power applet definitely worked, though power applet is too slow in my opinion.
Last time I checked the dimming was LM18.2

@clefebvre

This comment has been minimized.

Copy link
Member

commented Jun 22, 2018

ah sorry I didn't notice :)

OK, for dimming, looking at the code it's just out of luck, because it never dims on AC, so when the idle timeouts it checks the UP state, whereas for other things, it sets the timeout from the beginning based on the UP state. Anyway, I'm not I explain this right, but it's pretty clear to me what's wrong in CSD and we'll get this fixed either today or tomorrow.

@clefebvre clefebvre closed this in 8f52de6 Jun 22, 2018

@koshkamau

This comment has been minimized.

Copy link
Author

commented Jul 29, 2018

Is this problem a consequence of fixing the current issue or it is just a coincidence :) ?
https://forums.linuxmint.com/viewtopic.php?t=273378

In my opinion any Desktop Linux distribution asks for password too often for mere home usage, but now my laptop wants to be sure that the person who is opening the lid is the same who closed it a minute ago on the way to the kitchen...

@jerkey

This comment has been minimized.

Copy link

commented Feb 11, 2019

@koshkamau thank you so much for discovering this bug and pressing for its repair, and putting so much work into figuring out a workaround until it was supposedly finally fixed. Your report saved me! Thank you thank you thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.