Bug 297068 - When shutting down via Lock Screen, the sleep countdown runs first
Summary: When shutting down via Lock Screen, the sleep countdown runs first
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Active
Classification: Plasma
Component: General (show other bugs)
Version: PA 2
Platform: Meego/Harmattan Linux
: LO minor
Target Milestone: unscheduled
Assignee: active
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-29 19:35 UTC by Thomas Pfeiffer
Modified: 2019-04-23 15:56 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Pfeiffer 2012-03-29 19:35:13 UTC
When I activate the Shutdown slider in the Lock Screen, the following happens:
- The Lock Screen shortly disappears
- The Lock Screen reappers and the Sleep countdown starts again
- Once the countdown has finished, the device shuts down

The shutdown should be initiated immediately. In case we want a countdown for the shutdown (so users could still cancel if they had accidentally initiated it), the countdown should not be on the Sleeping side.
But imo there just should be no countdown for shutdown.
Comment 1 Lamarque V. Souza 2012-03-29 20:24:40 UTC
I had already noticed those problems:

1. The lock screen disappears because ksmserver (a KDE program) closes all user programas before exiting and ending the KDE session.

2. kwin is the last program ksmserver closes before exiting. I think kwin is re-launching the lock screen when it notices it was closed.

3. Since ksmserver gets the list of programs to kill before start killing processes the new lock  screen is not killed and lonly disappears when Xorg is closed and the system proceed with the shutdown process.

The shutdown is slow because ksmserver first try to contact each program for them to save their data and close themselves gracefully. If we do a fast shutdown we will be risking losing user data. The shutdown can also be very slow (2 or more minutes) if there are too much data on the swap partition.

If we move the lockscreen code to ksmserver I think that will prevent the second launch of the lock screen and there will be no countdown after triggering the shutdown process too.
Comment 2 Lamarque V. Souza 2012-03-30 14:50:37 UTC
I took a look at the kwin-screenlocker.diff patch from kde-workspace package and it is a very intrusive change. We are planning to build a stable image in the next few weeks I think we should postpone porting screenlocker to ksmserver for another time.
Comment 3 Lamarque V. Souza 2012-04-17 21:14:27 UTC
Ok, I moved screenlocker to ksmserver: https://build.pub.meego.com/package/rdiff?linkrev=base&package=kde-workspace&project=Project%3AKDE%3ADevel&rev=302

Now there is one less executable in kde-workspace (kscreenlocker is now a static library linked against libkdeinit4_ksmserver.so), there is still another executable (kscreenlocker_greet) that is responsible for drawing the QML unlock screen (the one with the clock). I changed ksmserver to close screenlocker right before closing the window manager, that is needed to prevent kwin from becoming a "zoombie". Because of that sometimes you will still be able to see the home screen before the computer finally shuts down. We could move the greeter into ksmserver to prevent that but that would increase the memory used by ksmserver since now the greeter is running only when the screen is locked.
Comment 4 Thomas Lübking 2012-04-24 18:41:39 UTC
I'm not aware that (vanilla) kwin would launch the screenlocker - it's actually handled by krunner (on "regular" KDE)

What you observe would likely (for a very short time) rather be an outcome of bug #158262 and by this fixed by https://git.reviewboard.kde.org/r/104519/
(!warning! - that particular commit actually contains crash prone statements)

A window being closed becomes (visually) raised above all other windows (including the screenlocker) for the duration of it's closing animation (if there's such)
Comment 5 Lamarque V. Souza 2012-04-24 19:11:19 UTC
(In reply to comment #4)
> I'm not aware that (vanilla) kwin would launch the screenlocker - it's
> actually handled by krunner (on "regular" KDE)

You're right, kwin does not launch kscreenlocker (that was my misunderstanding). kscreenlocker is launched by dbus if anyone tries to access its services (auto-launch dbus feature). We use branch screenlocker from kde-workspace in Plasma Active, in that branch kscreenlocker was implemented as a standalone process and now I merged it into ksmserver. The kscreenlocker just locks the screen with a fully transparent window, there is another process (kscreenlocker_greeter) that draws the unlock dialog used in Plasma Active and that dialog is the one Thomas Pfeiffer is talking about.
 
> What you observe would likely (for a very short time) rather be an outcome
> of bug #158262 and by this fixed by https://git.reviewboard.kde.org/r/104519/
> (!warning! - that particular commit actually contains crash prone statements)
> 
> A window being closed becomes (visually) raised above all other windows
> (including the screenlocker) for the duration of it's closing animation (if
> there's such)

Well, in this case we really want the window to be above all others since the window in question is the unlock screen dialog. Preferrebly the dialog should stay there until the device is turned off but ksmserver closes the greeter right before closing kwin and itself afterwards, so for a short time there will be no unlock screen like Thomes described.
Comment 6 Thomas Lübking 2012-04-24 20:50:01 UTC
(In reply to comment #5)

> should stay there until the device is turned off but ksmserver closes the
> greeter right before closing kwin and itself afterwards, so for a short time
> there will be no unlock screen like Thomes described.

Did you try to grab the X server (not simply the input)?
This should stop any visual updates.

On a more "naive" approach, ksmserver could dump the screen into a pixmap, open an override redirect window (unmanaged window), in doubt raise it (i think you'll have to use X11 directly, iirc. Qt only raises by windowmanager requests - i however also guess for your case it should be sufficient that it will be initially put on top of the stack anyway) and paint the dump onto that curtain (while closing the stuff below)
Comment 7 Thomas Pfeiffer 2012-09-13 20:21:41 UTC
The countdown does not appear anymore on basyskom-plasma-active-wetab-exopc-tablet-mer-testing-120913-1410.iso, however the lockscreen still disappears for some milliseconds. Now it's far less annoying, but still a visible imperfection.