Bug 348850

That is strange. We explicitly make the screen locker block the suspend (in case you have logind which I assume given it's Kubuntu) until it has fully started up. Any ideas on this one, Martin?

can you please post the output of:
qdbus org.kde.KWin /KWin supportInformation

Please post the information required in comment #2.

Sorry for the delay. Here you are:

KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.

==========================

Version
=======
KWin version: 5.2.2
Qt Version: 5.4.1

Operation Mode: X11 only

Decoration
==========
Plugin: org.kde.breeze
Theme: 
Blur: 0
onAllDesktopsAvailable: false
alphaChannelSupported: false
closeOnDoubleClickOnMenu: false
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
borderSize: 3
gridUnit: 10
font: Oxygen-Sans,10,-1,0,50,0,0,0,0,0
smallSpacing: 2
largeSpacing: 10

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
showDesktopIsMinimizeAll: false
rollOverDesktops: true
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 5000
operationMaxButtonLeftClick: 5000
operationMaxButtonMiddleClick: 5015
operationMaxButtonRightClick: 5014
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
condensedTitle: false
electricBorderMaximize: true
electricBorderTiling: true
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: true
compositingMode: 1
useCompositing: false
compositingInitialized: false
hiddenPreviews: 1
unredirectFullscreen: false
glSmoothScale: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glStrictBinding: true
glStrictBindingFollowsDriver: true
glCoreProfile: false
glPreferBufferSwap: 97
glPlatformInterface: 1

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 1x1
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 1
Screen 0 Geometry: 0,0,1366x768

Compositing
===========
Compositing is not active

thanks

You don't have compositing enabled. Can you please also paste the output of glxinfo.

Created attachment 93272 [details]
glxinfo output

Created attachment 93273 [details]
KWin supportInformation output

I have upgraded to Kubuntu 15.10 and observe the same behaviour. I have attached the latest information.

can you please test with compositing enabled? I'm relatively sure that this is just stale image presented by either hardware, driver or X server.

I could, but I can assure you that I can see the clock ticking (I have seconds enabled), so it's not a stale image.

OTOH, this seems to be linked to swapping or other hard disk activity. Like if the process meant to obfuscate the screen had no chance to do so before the computer had resumed for a few seconds.

Note: contrarily from I state above, this is not always the case, which led me to accusing the hard disk activity.

So maybe the suspend should be blocked until we're sure the screen has been obfuscated?

If I understood the code correctly, the inhibition is removed once the greeter process is started, not once the greeter window is shown. So yes, there can be an improvement.

*** Bug 350268 has been marked as a duplicate of this bug. ***

Git commit 1be3ba05370b4f9e9f7515ca8035883ac2da341b by Martin Gräßlin.
Committed on 25/08/2015 at 08:28.
Pushed by graesslin into branch 'master'.

[screenlocker] Emit locked once the lock window is shown

The screen is only truly locked once our black background window is
shown. So far we locked once the greeter process was started. At this
point the screen was still unlocked and a suspend would result in system
waking up with an unlocked screen for a brief period.

This change emits the locked signal once we got a MapNotify event for
our black background window which means the screen is properly turned
black and we can allow e.g. going to suspend.
REVIEW: 124912

M  +7    -7    ksmserver/screenlocker/ksldapp.cpp
M  +1    -0    ksmserver/screenlocker/lockwindow.cpp
M  +1    -0    ksmserver/screenlocker/lockwindow.h

http://commits.kde.org/plasma-workspace/1be3ba05370b4f9e9f7515ca8035883ac2da341b

Assuming my fix improved the situation. If you still experience with Plasma 5.5 please reopen.