KDE Energy Saving: No login mask after resume from sleep (openSUSE 13.1)

English Applications
#1

I’m experiencing the following issue with KDE’s Energy Saving option “Suspend Session”: After resuming from sleep mode, no login mask is displayed, only the splash screen appears. I can switch to tty1 (<Ctrl> + <Alt> + <F1>), login as root, and do a [FONT=system]service xdm restart; but then all data of the suspended session are lost.
I’ve noticed the following details:[/FONT]

  • The issue appears only, when suspending the session automatically, i. e. timer controlled. Returning from a manually initiated sleep mode works just fine.

  • The issue did not
    exist in openSUSE 12.3 (KDE 4.10.5), and earlier.

  • The issue seems to be HW independent: I have it an all 3 laptops (Acer, Lenovo, Toshiba).

OS data:
openSUSE 13.1 (Bottle) (x86_64), Linux 3.11.10-7-desktop
KDE Version 4.11.5

Helpful hints are very much appreciated!

Thanks,
Dirk

#2

Yes, this bug got introduced in KDE 4.11.4 and has been fixed in the meantime.
See also:
http://forums.opensuse.org/showthread.php/495223-After-suspend-sleep-can-t-login
https://bugzilla.novell.com/show_bug.cgi?id=864305

Workarounds:

  • Press Ctrl+Alt+F1 and kill the screenlocker with “killall kscreenlocker_greet”, then the password dialog should appear
  • enable “Require Password after” in the screen locker settings
  • disable “Lock Screen after resume” in the powermanagement settings (“Advanced”)
  • Upgrade your KDE to the latest version from KDE:Current

An update for openSUSE 13.1 is already in the works and should appear soon in the standard update repo.

PS: I have created testing packages with the fix for standard 13.1 that are available here:
http://download.opensuse.org/repositories/home:/wolfi323:/branches:/openSUSE:/13.1:/Update/standard/
(you only need kdebase4-workspace)

#3

Hello Dirk,
I faced the same issue on 12.3. I solved it for me by disabling the automatic start of screen lock in system settings:
(“Systemeinstellungen” - Anzeige und Monitor - Bildschirmsperre: Haken entfernen bei !Automatischer Start nach …" .)

Regards,
Holger

#4

On 12.3?
Did you use an upgraded KDE? (from KDE:Release:411 f.e.)

As I said, that bug got introduced with 4.11.4 when another bug was fixed, namely that the screen locker always showed the password dialog, even when no password was required.
12.3’s KDE 4.10 still has that other bug and is therefore not affected by this one…

I solved it for me by disabling the automatic start of screen lock in system settings:
(“Systemeinstellungen” - Anzeige und Monitor - Bildschirmsperre: Haken entfernen bei !Automatischer Start nach …" .)

Yes, this is another workaround.
The problem only occurs when the screen locker/saver kicks in before the system is suspended automatically (or rather locked because of the “Lock Screen after resume” setting).

#5

Great! Thanks a lot, Wolfgang and Holger!

I’ve successfully tested the various workarounds (except KDE upgrade). They all work fine! The best combination for my purposes is the following:

System Settings - Power Management - Energy Saving - Suspend Session: ENABLED (checked) and set to SLEEP after x minutes
System Settings - Power Management - Advanced Settings - Lock Screen on resume: ENABLED (checked)
System Settings - Display and Monitor - Screen Locker - Start automatically after: ENABLED (checked) and set to y minutes
System Settings - Display and Monitor - Screen Locker - Require password after: ENABLED (checked) and set to z minutes
(This combination works fine, as long as x > y + z, i. e. if the password lock is active before the suspend starts.)

Looking forward to the bug fix,
Dirk

#6

Not quite.

The password dialog should appear in any case after y+z IIRC.
But obviously you have to wait some time for it to appear after the resume though, if x < y + z.

Example:
Set screen locker to appear after 1 min., set “require password after” 2 minutes, and set “Suspend Session after” 2 minutes.
When you resume, the password dialog should be shown 1 minute later.

Looking forward to the bug fix,

The package has been submitted to the maintenance process already, if all goes well this takes about a week until release.