This forum has been archived. All content is frozen. Please use KDE Discuss instead.

long pause between closing laptop lid and suspend to ram

Tags: None
(comma "," separated)
dutchkind
Registered Member
Posts
16
Karma
0
OS
I have set powermanagement to suspend to ram whenever I close the lid of my laptop. However, when I close the lid it takes at least 10 seconds before it starts suspending while when I click the button "suspend to ram" in powermanagement it suspends immediately. Do other users have the same? Is this configurable in some way or is this just a bug or feature?
It can be quite annoying having to wait for it to suspend, and I prefer to see it go into suspend because it has happened to me that I thought it would suspend and when I got back it had been running all the time.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
An analysis of the KDE Power Management code indicates that there is no reason for this delay.
Can you please run the following command, then close the lid - and quickly reopen it?
Code: Select all
upower --monitor-detail


If it prints nothing, then it means that either UPower itself - or BIOS software - is delaying the recognition of the lid closure and thus preventing KDE Power Management from being aware of this.

You will probably see something like this get printed out if it did detect the change (in which case the issue is in the KDE side):
Code: Select all
[18:50:10.653]  daemon changed:
  daemon-version:  0.9.14
  can-suspend:     yes
  can-hibernate    no
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   yes
  lid-is-present:  yes
  is-docked:       no

[18:50:11.984]  daemon changed:
  daemon-version:  0.9.14
  can-suspend:     yes
  can-hibernate    no
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
dutchkind
Registered Member
Posts
16
Karma
0
OS
Sorry, forgot to look at this post.

I just tried and closing the lid doesn't give any feedback to the upower konsole.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
This would explain the long pause then, as KDE cannot take any action if it is not being informed of when the lid has been closed.
Not much we can do i'm afraid, although you could try checking with the UPower folks to see why this notification is not being sent.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
dutchkind
Registered Member
Posts
16
Karma
0
OS
The strange thing is though that the moment I close the lid the screen is blanked, so something is being noticed. Or is this a hardware thing?
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
This could very well be a hardware thing - on my system changing the brightness even works in the BIOS and GRUB boot menu - ie. it is handled at a hardware / system software level.

If UPower is not sending an event, then KDE cannot notice it unfortunately. It could very well be that there is a bug in UPower preventing it from detecting the lid closure.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
dutchkind
Registered Member
Posts
16
Karma
0
OS
I did some more testing, when I test with upower, as soon as I unplug and re-plug the power cord I see an event for that, but also the lid stuff is found. So somehow it takes a long time for upower to detect the closed lid, because after all, after about 15 seconds the machine goes into sleep. Is there a way I can change/edit stuff to test if it can be resolved? I assume more users have the same laptop, so it would solve this for more people.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
Unfortunately I don't know any way of debugging UPower itself, you would be best to ask the developers of it instead.
You may need to compile and install system wide software to conduct your tests.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
dutchkind
Registered Member
Posts
16
Karma
0
OS
ok, thanks. I will think about it, or try this via the distro. Compiling is not a big issue for me, but for packets that have such system wide implications I prefer someone is involved that knows more about the stuff.
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
The UPower developers would likely be the best ones to contact here, as they will have the knowledge needed to ascertain where this bug might be (whether in the hardware, kernel drivers, kernel itself or UDev/UPower).


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
dutchkind
Registered Member
Posts
16
Karma
0
OS
I will see if I can get in touch with the upower developers.


Bookmarks



Who is online

Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]