Bug 205453 - Closing laptop lid not working when screensaver is active
Summary: Closing laptop lid not working when screensaver is active
Status: RESOLVED DUPLICATE of bug 209511
Alias: None
Product: solid
Classification: Unmaintained
Component: powermanagement-daemon (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-28 09:26 UTC by Sjoerd Hardeman
Modified: 2010-11-09 20:41 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
remove unnecessary check (431 bytes, patch)
2010-05-10 00:11 UTC, debianbug
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sjoerd Hardeman 2009-08-28 09:26:18 UTC
Version:            (using KDE 4.2.4)
Compiler:          g++ (Debian 4.3.4-1) 4.3.4 
OS:                Linux
Installed from:    Debian testing/unstable Packages

I have configured powerdevil to enable sleep when I close the laptop lid. This works, except when the screensaver is active. In that case nothing happens.
I have not password-protected my screensaver.
The same happens (of course) when I lock my screen. Also in that case closing the lid should enable the configured action.
Comment 1 neotekltd 2009-08-28 10:50:54 UTC
I am experiencing the same problem using openSUSE11.1 with KDE4.2.4
Comment 2 Oren Held 2009-08-28 20:39:20 UTC
Same with KDE 4.3.0 (debian sid). No screensaver, even when the screen is simply locked, lid close is just being ignored.
Comment 3 Oren Held 2009-09-05 21:06:05 UTC
Confirmed also on 4.3.1
This is quite a serious bug imo, my laptop almost got fried inside my bag, cuz I trusted it to be suspended while it wasn't.

Please set this bug as confirmed. it's very easily reproducible.
Comment 4 andrew 2010-01-31 13:30:48 UTC
Same problem and it is a serious issue needing a fix.  Here is a use case:

1. From an active session, close lid on laptop; power mangement evokes susspend to ram
2. friend later opens and wakes laptop but finds screen locked
3. friend closes lid on laptop expecting it to susspend again
4. susspend is never evoked and battery runs flat

NB. even if the friend notice that the lappy didn't susspend there is no way he can force it to.  The screen lock dialog has no button for this purpose: its log in or nothing.

Seriously, this stuff should work much better than it does - we nearly upto 4.4 after all!
Comment 5 Decha 2010-02-17 10:22:46 UTC
Same here on gentoo:
  Qt: 4.5.3
  KDE: 4.3.3 (KDE 4.3.3)
Comment 6 andrew 2010-02-17 12:49:06 UTC
This problem is still present in KDE 4.4
Comment 7 debianbug 2010-05-10 00:11:39 UTC
Created attachment 43416 [details]
remove unnecessary check
Comment 8 debianbug 2010-05-10 00:21:08 UTC
Comment on attachment 43416 [details]
remove unnecessary check

Patch for KDE SC 4.4.3
All cases tested (shutdown, S2Disk, S2Ram, Standby, Lock, TurnOffScreen, default)
With and without active screensaver.
Comment 9 Erik Johnson 2010-05-11 20:47:06 UTC
(In reply to comment #8)
> (From update of attachment 43416 [details])
> Patch for KDE SC 4.4.3
> All cases tested (shutdown, S2Disk, S2Ram, Standby, Lock, TurnOffScreen,
> default)
> With and without active screensaver.

I can confirm that this patch works. Thanks!
Comment 10 Stephen Dunn 2010-07-30 11:31:26 UTC
Hi

This is still being reported as a problem in 4.4.4 in openSUSE 11.3

https://bugzilla.novell.com/show_bug.cgi?id=439709
Comment 11 Sjoerd Hardeman 2010-07-30 14:09:46 UTC
I can confirm that also on current Debian testing using KDE 4.4.3 this bug is still unsolved.
Comment 12 archtaku 2010-07-30 17:40:37 UTC
@#10, #11:

Did either of you try rebuilding with the patch referenced in comment #7 (https://bugs.kde.org/show_bug.cgi?id=205453#c7)? I rebuilt kdebase-workspace in Arch Linux after applying the patch, and it's worked since then.
Comment 13 Jack Erwin 2010-08-11 22:24:26 UTC
Still a problem in 4.5.  Can we get this applied?
Comment 14 Dario Freddi 2010-11-09 20:41:35 UTC

*** This bug has been marked as a duplicate of bug 209511 ***