Do you have an NVIDIA GPU?

(In reply to Nate Graham from comment #1)
> Do you have an NVIDIA GPU?

No, amd 6700 XT, using amdgpu drivers

Sorry for the late reply, I couldn't find this bug report (search is set to a certain set of possible bug states, one of which is not NEEDSINFO.
Problem persists with qt 6.7 beta 3

I notice you're moving the mouse *immediately* after locking the screen and before the wallpaper of the lock screen appears. We had a bug report on this and I recall it being fixed and I can't reproduce the isste myself right now, but I'm having trouble finding the bug report now. Will keep looking.

(In reply to Nate Graham from comment #4)
> I notice you're moving the mouse *immediately* after locking the screen and
> before the wallpaper of the lock screen appears. We had a bug report on this
> and I recall it being fixed and I can't reproduce the isste myself right
> now, but I'm having trouble finding the bug report now. Will keep looking.

BUG 479659

Thanks!

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

(In reply to Nate Graham from comment #4)
> I notice you're moving the mouse *immediately* after locking the screen and
> before the wallpaper of the lock screen appears. We had a bug report on this
> and I recall it being fixed and I can't reproduce the isste myself right
> now, but I'm having trouble finding the bug report now. Will keep looking.

Astute observation but done only to demonstrate that the lock screen password input doesn't show up in a timely manner. I get the same bug if I don't touch my mouse for arbitrary amount of time.

Darn. So you *always* see a black screen with a movable cursor?

If you type your password blindly and hit the enter key, does it unlock?

And is this happening on Wayland, or X11, or both?

(In reply to Nate Graham from comment #8)
> Darn. So you *always* see a black screen with a movable cursor?
> 
> If you type your password blindly and hit the enter key, does it unlock?
> 
> And is this happening on Wayland, or X11, or both?

Correct, I always get the black screen *before* and *after* unlocking. Typing in password blindly and hitting enter does unlock it but produces another black screen that doesn't go away until certain amount of time has passed and I've made a mouse click. This is only happening on X11.

> Correct, I always get the black screen *before* and *after* unlocking.

That makes me wonder whether the fix for Bug 477916 (https://invent.kde.org/plasma/kwin/-/merge_requests/5240, which made it into the final Plasma 6.0 release) applies here as well. Although I was looking at Wayland there, not sure if X11 hits the same codepath or if perhaps there's a similar bug hidden in a different spot.

(In reply to Jakob Petsovits from comment #10)
> > Correct, I always get the black screen *before* and *after* unlocking.
> 
> That makes me wonder whether the fix for Bug 477916
> (https://invent.kde.org/plasma/kwin/-/merge_requests/5240, which made it
> into the final Plasma 6.0 release) applies here as well. Although I was
> looking at Wayland there, not sure if X11 hits the same codepath or if
> perhaps there's a similar bug hidden in a different spot.

I'll update the bug report once plasma 6 final is out on Arch to let you know

Unfortunately, I can reproduce it on final Plasma 6 too.

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

(In reply to pmargeti34 from comment #13)
> *** Bug 482054 has been marked as a duplicate of this bug. ***

For the record, "multiple issues" is not a great title (or general concept) for a bug report. If the issues are independent, it gets harder to track them individually within a single thread. So I'm not super excited to see another bug closed as duplicate that had a clearer title and scope than this one. Although the video for this one is very helpful, thanks for including that. Too bad Bugzilla doesn't provide better tools to merge threads or at least modify the bug description at the top.

Anyway, the faulty ENTER/RETURN issue is now marked as fixed, so could we rescope this bug (and rename the title) to just the X11 blank-with-cursor problem?

(In reply to Jakob Petsovits from comment #14)
> (In reply to pmargeti34 from comment #13)
> > *** Bug 482054 has been marked as a duplicate of this bug. ***
> 
> For the record, "multiple issues" is not a great title (or general concept)
> for a bug report. If the issues are independent, it gets harder to track
> them individually within a single thread. So I'm not super excited to see
> another bug closed as duplicate that had a clearer title and scope than this
> one. Although the video for this one is very helpful, thanks for including
> that. Too bad Bugzilla doesn't provide better tools to merge threads or at
> least modify the bug description at the top.
> 
> Anyway, the faulty ENTER/RETURN issue is now marked as fixed, so could we
> rescope this bug (and rename the title) to just the X11 blank-with-cursor
> problem?

Agreed. issue has been renamed to something hopefully more adequate. If it's more convenient for you or other parties involved, I'm perfectly fine with this bug closed in favor of the other one. My reasoning for marking the other one as duplicate was it's timestamp, this one preceded it.

Thanks. Let's keep this one and look at Bug 482054 as a second reference / for reproduction steps.

I can't reproduce on my (Intel integrated graphics) ThinkPad X1 Carbon Gen 7 btw. Sorry. I don't think there's enough logging code in the PowerDevil DPMS action (where I suspect this to be triggered) so I'd have to see if I can set up a Plasma development environment on my desktop PC with AMD graphics, or perhaps it will reproduce with Arch packages once they go into stable. Let me try packing in some extra debug logs for 6.0.1 so we have more to go on.

Also, in the Energy Savings KCM, what's your setting for "When locked, turn off screen"?

(In reply to Jakob Petsovits from comment #16)
>perhaps it will reproduce with Arch packages once they go into stable.
doubt it, I've reported this in RC2, there's a good chance this bug was lurking in RC1 just didn't get reported. Most people, myself included, were focused on wayland session.

> Also, in the Energy Savings KCM, what's your setting for "When locked, turn
> off screen"?

Setting is disabled, I'm not using any energy saving settings.

Exact same issue here, as shown in video attachment. It happens consistently as soon as I enter screen lock.
Problem started when upgrading to Qt6. Same PC had Qt5, without any issue.

Screen is connected to PC via HDMI, and when returning from a screen lock (blindly typing the password) not only it struggles to reactivate the screen (only mouse pointer is visible on a black screen), but also HDMI audio isn’t functioning properly (it goes on and off untill screen is finally available).

Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-21-generic (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Celeron® CPU J3455 @ 1.50GHz
Memory: 5.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 500

Can confirm on Arch Linux current on my laptop, upgraded this morning to plasma 6. No monitor attached, issue occurs on the laptop screen directly. As soon as I lock screen, either via application launcher or via keyboard shortcut, screen goes blank but I can see cursor if I move it, as per previous comments. I can type my password blindly and it unlocks screen and screen is visible again. Perhaps worth mentioning that I get the issue 19 times out of 20. Very rarely, the lock screen works as expected.

Also
/usr/lib/kscreenlocker_greet --testing
always works fine.

SOFTWARE/OS VERSIONS
Linux: linux 6.7.8-arch1-1
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Memory: 13.6 GiB of RAM
Graphics Processor: AMD Radeon Vega 10 Graphics
Manufacturer: ASUSTeK COMPUTER INC.

So, quick recap:

- It's not specific to any GPU vendor. We have all three of Intel, AMD and Nvidia reported.
- It's not specific to having monitors or laptop displays.
- It's not specific to Arch Linux, as KDE neon also gets a mention.

With such a wide range of scenarios covered, it feels like reproducing this should be straightforward except for me it's not. If any other KDE developer experiences this on their system, please get in touch. 

Thanks everyone for chiming in with system configurations. Just to make sure, the trick from the corresponding (now fixed) Wayland bug doesn't help here, where you press Esc twice to make the display come back? (once to hide the screen locker and properly turn off the screen, the second time to bring it back)

Plasma 6.0 got released to stable on Arch Linux. Unfortunately I can't reproduce it with the official packages either.

Plenty of repros here, but thought I'd add another one just in case. Screen lock turns off the screen; moving my mouse/clicking wakes my screen up and shows the cursor. Couple of seconds pass, lockscreen UI pops up. Once I log in, screen fades to black for like 30 seconds with cursor reappearing shortly afterwards, then everything fades back in eventually.

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.8-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2

(In reply to Jakob Petsovits from comment #20)
> Just to make sure, the trick from the corresponding (now fixed) Wayland bug doesn't help
> here, where you press Esc twice to make the display come back? (once to hide
> the screen locker and properly turn off the screen, the second time to bring
> it back)

Can confirm this doesn't do anything.

(In reply to Jakob Petsovits from comment #20)
> So, quick recap:
> 
> - It's not specific to any GPU vendor. We have all three of Intel, AMD and
> Nvidia reported.
> - It's not specific to having monitors or laptop displays.
> - It's not specific to Arch Linux, as KDE neon also gets a mention.
> 
> With such a wide range of scenarios covered, it feels like reproducing this
> should be straightforward except for me it's not. If any other KDE developer
> experiences this on their system, please get in touch. 
> 
> Thanks everyone for chiming in with system configurations. Just to make
> sure, the trick from the corresponding (now fixed) Wayland bug doesn't help
> here, where you press Esc twice to make the display come back? (once to hide
> the screen locker and properly turn off the screen, the second time to bring
> it back)

For me, all that does is shut down the monitor again, so I have to move the cursor for it to wake up again and eventually get the blank screen.
Also doesn't seem to do anything once I unlock the screen and get another blank (desktop) screen where the monitor shuts down. Meta key eventually does brink the screen back, though (~10-15 seconds later).

> Thanks everyone for chiming in with system configurations. Just to make
> sure, the trick from the corresponding (now fixed) Wayland bug doesn't help
> here, where you press Esc twice to make the display come back? (once to hide
> the screen locker and properly turn off the screen, the second time to bring
> it back)

Not for me. If anything, it shows very odd behaviour.
When I lock screen:
- screen will be blank
- first Esc keypress will cause screen to turn off
- second Esc keypress will cause it to turn on again for a moment (but blank), and then the screen will turn off after a second
- subsequente Esc keypresses will do the same (screen on for a second but blank, then turning off)
- moving the mouse, unlike the Esc keypress, causes the screen to stay on (although still blank)

In case it helps, this behaviour is somewhat reproducible with" kscreenlocker_greet --testing" too:
- launching the testing screen will work fine (lock screen content is visible within a decorated window)
- pressing Esc will cause the screen to turn off
- a second Esc keypress will cause the screen to turn on again, but it will turn off on its own after a second
-  moving the mouse, unlike the Esc keypress, causes the he testing screen to stay on (with content visible)

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

can confirm  this happens for me on two separate machines.

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

Something I don't see elsewhere on this thread: when this happens to me, I can use Ctrl+Alt+F3 to switch to TTY 3 and then Alt+F2 back to TTY 2, and the screen locker looks correct immediately instead of me having to wait.

System info per "neofetch --off":

OS: EndeavourOS Linux x86_64 
Kernel: 6.7.8-arch1-1 
Uptime: 1 day, 35 mins 
Packages: 2271 (pacman) 
Shell: zsh 5.9 
Resolution: 2560x1440 
DE: Plasma 6.0.1 
WM: KWin 
Theme: [Plasma], Breeze-Dark [GTK2], Breeze [GTK3] 
Icons: [Plasma], breeze [GTK2/3] 
Terminal: terminator 
CPU: AMD Ryzen 9 7950X (32) @ 5.881GHz 
GPU: AMD ATI 6d:00.0 Raphael 
GPU: AMD ATI Radeon RX 6800/6800 XT / 6900 XT 
Memory: 8224MiB / 127936MiB

Vlad from the KWin team found the cause of the bug and I can reproduce it now. Working on a fix. And yes, it's my fault. Sorry everyone!

A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/332

Tried applying the patch in the powerdevil merge request and rebuilt/installed poweredevil. From what I can tell it had no impact on either the escape key behavior or the blank lock screen render.

I notice that when I get the black screen with mouse cursor, I can move the mouse over where the password field should be and it turns into the I-beam cursor, and I am able to type in the field and unlock the screen. Doing so causes it to present a few frames of what the locker *should* have been rendering before the locker exits. And I can run `kscreenlocker_greet --test` (or without `--test`) and it renders fine, so I'm not sure exactly what is causing it to render the black screen.

(In reply to Bug Janitor Service from comment #31)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/powerdevil/-/merge_requests/332

Following the logic of this merge request, I was able to fix the problem on my PC by:
- enabling automatic screen turn-off;
- setting a long-enough LockGrace period.
In my case, LockGrace has to be at least 15 seconds; as soon as it’s set lower, the unintentional screen turn-off happens again.

Thanks Luke, That fixed mine as well.
Just wait now for an update to PowerDevil
KS

(In reply to Steven Noonan from comment #32)
> Tried applying the patch in the powerdevil merge request and
> rebuilt/installed poweredevil. From what I can tell it had no impact on
> either the escape key behavior or the blank lock screen render.

Same, patch does not seem to change behaviour. Also FWIW, I have turn off screen automatically after 5 mins in Energy Saving config, and allow unlocking without password for 15 seconds in Screen Locking config.

(In reply to Luke from comment #33)
> (In reply to Bug Janitor Service from comment #31)
> > A possibly relevant merge request was started @
> > https://invent.kde.org/plasma/powerdevil/-/merge_requests/332
> 
> Following the logic of this merge request, I was able to fix the problem on
> my PC by:
> - enabling automatic screen turn-off;
> - setting a long-enough LockGrace period.
> In my case, LockGrace has to be at least 15 seconds; as soon as it’s set
> lower, the unintentional screen turn-off happens again.

Can confirm that this setting works. At 15 seconds or more the expected behavior comes back, seeing the lock screen and the screen does not turn off either when locking nor unlocking. Thanks!

(In reply to Steven Noonan from comment #32)
> Tried applying the patch in the powerdevil merge request and
> rebuilt/installed poweredevil. From what I can tell it had no impact on
> either the escape key behavior or the blank lock screen render.

(In reply to Giacomo Lozito from comment #35)
> Same, patch does not seem to change behaviour. Also FWIW, I have turn off
> screen automatically after 5 mins in Energy Saving config, and allow
> unlocking without password for 15 seconds in Screen Locking config.

Thanks for testing, much appreciated. I'm unclear as to why the fix wouldn't be working. Given that you have a built-from-souce setup, could you do two more things to help out?

1. Please make sure that $PREFIX/lib/plugins/powerdevil/action/powerdevil_dpmsaction.so was installed in addition to the powerdevil binary itself. That's where the power management service's screen turn-off logic (and the proposed fix) is located in practice.

2. Please provide some of that new debug output that I added in the same commit, to get a rough understanding of how your screen turns blank. On a system with systemd, the easiest way to make the extra logs show up in journalctl is:

systemctl edit --user plasma-powerdevil.service

and in the free space between the top two comment paragraphs, add this line:

[Service]
Environment="QT_LOGGING_RULES=org.kde.powerdevil=true"

The new logging entries all start with "org.kde.powerdevil: DPMS:", they describe what idle timeouts are set for the action to trigger and when the screen actually gets turned off. Please paste some of those logs here. If that's an issue because the screen is blank, I've found that switching between virtual terminals (e.g. Ctrl+Alt+F7 and back to the original one, wherever it's located as per `loginctl list-sessions`) will restore the screen to non-black.

Thanks!

(In reply to Jakob Petsovits from comment #37)
> (In reply to Steven Noonan from comment #32)
> > Tried applying the patch in the powerdevil merge request and
> > rebuilt/installed poweredevil. From what I can tell it had no impact on
> > either the escape key behavior or the blank lock screen render.
> 
> (In reply to Giacomo Lozito from comment #35)
> > Same, patch does not seem to change behaviour. Also FWIW, I have turn off
> > screen automatically after 5 mins in Energy Saving config, and allow
> > unlocking without password for 15 seconds in Screen Locking config.
> 
> Thanks for testing, much appreciated. I'm unclear as to why the fix wouldn't
> be working. Given that you have a built-from-souce setup, could you do two
> more things to help out?
> 
> 1. Please make sure that
> $PREFIX/lib/plugins/powerdevil/action/powerdevil_dpmsaction.so was installed
> in addition to the powerdevil binary itself. That's where the power
> management service's screen turn-off logic (and the proposed fix) is located
> in practice.
> 
> 2. Please provide some of that new debug output that I added in the same
> commit, to get a rough understanding of how your screen turns blank. On a
> system with systemd, the easiest way to make the extra logs show up in
> journalctl is:
> 
> systemctl edit --user plasma-powerdevil.service
> 
> and in the free space between the top two comment paragraphs, add this line:
> 
> [Service]
> Environment="QT_LOGGING_RULES=org.kde.powerdevil=true"
> 
> The new logging entries all start with "org.kde.powerdevil: DPMS:", they
> describe what idle timeouts are set for the action to trigger and when the
> screen actually gets turned off. Please paste some of those logs here. If
> that's an issue because the screen is blank, I've found that switching
> between virtual terminals (e.g. Ctrl+Alt+F7 and back to the original one,
> wherever it's located as per `loginctl list-sessions`) will restore the
> screen to non-black.
> 
> Thanks!

Happy to test.
For 1. I confirmed that /usr/lib/qt6/plugins/powerdevil/action/powerdevil_dpmsaction.so is included in the arch powerdevil package I patched and rebuilt. I also confirmed its md5sum being different before/after rebuild/reinstall to make sure it's been modified.

For 2. I have enabled logging and I can see some of the logging lines in question, more precisely (filtering only the powerdevil: DPMS lines):

Mar 09 17:00:20 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen lock activating) after 60000ms
Mar 09 17:00:22 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen unlocked) after 300000ms

Mar 09 17:00:39 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen lock activating) after 60000ms
Mar 09 17:00:43 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen unlocked) after 300000ms

Mar 09 17:01:23 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen unlocked) after 300000ms
Mar 09 17:01:20 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen lock activating) after 60000ms

Mar 09 17:02:13 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen lock activating) after 60000ms
Mar 09 17:02:25 arcadia org_kde_powerdevil[1211]: org.kde.powerdevil: DPMS: registering idle timeout (screen unlocked) after 300000ms

for each of the 4 attempts, the first line (screen lock activating) pops up as soon as I activate screen lock using Meta+L. The screen unlocked one comes up as I blindly type my password to unlock screen. Worth mentioning that one of these 4 attempts was "successful" (like I mentioned before, rarely the screenlock screen will show as expected). I also tried to switch virtual terminal in the fourth attempt, which  causes the screenlock screen to show correctly once switched back to, but does not seem to produce any additional log line of interest.

Note: reading those log lines and looking at where those are located in the patch, the impression I get is that my timeout for turning off the screen (60 seconds) is not being honored. Instead, it immediately proceeds to turn off the screen. This would also explain why I pressing esc turns on the screen for a moment for me, and then turns it off again (because instead of waiting 60 seconds, it's doing the fast display turn off without waiting for timeout).

(In reply to Giacomo Lozito from comment #39)
> Note: reading those log lines and looking at where those are located in the
> patch, the impression I get is that my timeout for turning off the screen
> (60 seconds) is not being honored. Instead, it immediately proceeds to turn
> off the screen. This would also explain why I pressing esc turns on the
> screen for a moment for me, and then turns it off again (because instead of
> waiting 60 seconds, it's doing the fast display turn off without waiting for
> timeout).

Thanks for the logs. What I'm noticing here is the lack of log messages for when the screen actually *does* get turned off. That would look something like:

org.kde.powerdevil: DPMS: starting to fade out
org.kde.powerdevil: DPMS: triggered on idle timeout, turning off display and keyboard backlight

or perhaps

org.kde.powerdevil: DPMS: DPMS: triggered from externally, type: "TurnOff"

If you're not seeing those, I have to wonder if perhaps some other component is independently turning off the screen that's unrelated to PowerDevil. (I also just noticed that I forgot adding a similar log entry to the third turn-off call, which should only get triggered if you assign and press the "Turn Off Screen" global keyboard shortcut.)

Although in my collection of Plasma source directories, the only other component I see that's calling KScreen::Dpms::switchMode (with Off parameter) is the screen locker in its Esc key handler. I figure that's not getting in the way here.

On that note, perhaps run a quick test with powerdevil stopped (i.e. `systemctl stop --user plasma-powerdevil.service`) to confirm that the DPMS action is actually responsible for this? Screen stays on with powerdevil stopped and turns blank with powerdevil running, yes?

> On that note, perhaps run a quick test with powerdevil stopped (i.e.
> `systemctl stop --user plasma-powerdevil.service`) to confirm that the DPMS
> action is actually responsible for this? Screen stays on with powerdevil
> stopped and turns blank with powerdevil running, yes?

Just done this test. The screen still goes blank as soon as I activate screen lock, even with powerdevil off, and obviously no powerdevil-related log lines appearing in journalctl.

> If you're not seeing those, I have to wonder if perhaps some other component
> is independently turning off the screen that's unrelated to PowerDevil.

There is an important detail here, which I reported incorrectly in my previous message, sorry. When I activate the screen lock, the screen goes blank, but not off (meaning that I can still see the screen backlight on, and the mouse cursor is visible if I move it). If I then press Esc, it goes off. If I press it again, the screen turns on (with nothing displayed, but the backlight is on) for a moment, then back off.

Based on logs, I think you are right on Powerdevil is not turning the screen off. But something is causing the screen lock not to be displayed (as if its window wasn't drawn?)

(In reply to Giacomo Lozito from comment #41)
> Based on logs, I think you are right on Powerdevil is not turning the screen
> off. But something is causing the screen lock not to be displayed (as if its
> window wasn't drawn?)

Okay, so then we've got two different bugs on our hands. My patch from https://invent.kde.org/plasma/powerdevil/-/merge_requests/332 should solve one. We'll still have to figure out where the other one comes from.

(In reply to Giacomo Lozito from comment #41)
> There is an important detail here, which I reported incorrectly in my
> previous message, sorry. When I activate the screen lock, the screen goes
> blank, but not off (meaning that I can still see the screen backlight on,
> and the mouse cursor is visible if I move it).

Right, thanks for pointing that out. Those are indeed different things, although I can only see the fade-out effect used by PowerDevil and nothing else (it sets a "_KDE_KWIN_KSCREEN_SUPPORT" atom for X11, implemented in KWin's KscreenEffect). The effect itself also triggers when a display is "aboutToTurnOff", which could be worth exploring too but seems somewhat unlikely.

At this point I wonder if there's maybe a second powerdevil running (for a different logged-in Plasma session?) with the old, unfixed code that still manages to activate the fade-out effect but doesn't manage to turn off the display. I wouldn't bet on it, but what other leads do we have at this point?

If it's the screen locker window not being drawn, the black screen (with visible cursor) should go away once you blindly unlock the session with your password. The fade-out effect hits all windows, whereas the screen locker on X11 is only a single window that sits on top of all the rest.

(In reply to Jakob Petsovits from comment #42)
> (In reply to Giacomo Lozito from comment #41)
> > Based on logs, I think you are right on Powerdevil is not turning the screen
> > off. But something is causing the screen lock not to be displayed (as if its
> > window wasn't drawn?)
> 
> Okay, so then we've got two different bugs on our hands. My patch from
> https://invent.kde.org/plasma/powerdevil/-/merge_requests/332 should solve
> one. We'll still have to figure out where the other one comes from.

For my specific issue, I just made some progress. I tried changing the plasma style away from breeze to breeze light and now the screen lock consistently shows up when I lock screen. Once I switch plasma style back to breeze, I can reproduce the issue again. Switching away from breeze to breeze dark or oxygen also fixes it. I have tried deleting ~/.cache on the off chance this is caused by a cached copy of breeze, but does not seem to help.

Anyway, even though this issue only manifests with the screen lock (and the symptoms are deceptively similar to what reported by others for powerdevil) my issue is unrelated with powerdevil.

(In reply to Giacomo Lozito from comment #43)
> (In reply to Jakob Petsovits from comment #42)
> > (In reply to Giacomo Lozito from comment #41)
> > > Based on logs, I think you are right on Powerdevil is not turning the screen
> > > off. But something is causing the screen lock not to be displayed (as if its
> > > window wasn't drawn?)
> > 
> > Okay, so then we've got two different bugs on our hands. My patch from
> > https://invent.kde.org/plasma/powerdevil/-/merge_requests/332 should solve
> > one. We'll still have to figure out where the other one comes from.
> 
> For my specific issue, I just made some progress. I tried changing the
> plasma style away from breeze to breeze light and now the screen lock
> consistently shows up when I lock screen. Once I switch plasma style back to
> breeze, I can reproduce the issue again. Switching away from breeze to
> breeze dark or oxygen also fixes it. I have tried deleting ~/.cache on the
> off chance this is caused by a cached copy of breeze, but does not seem to
> help.

Interesting. I tried switching between Breeze and Breeze Light, which on my dev session setup doesn't make any difference for the screen locker in that way. Great find though! And this also supports the theory of this "second" issue to be an issue with drawing the screen locker window as opposed to the KWin fade-out effect being inappropriately applied.

Not sure how best to deal with bug reports because ideally we'd have two separate ones, but if the symptoms are indeed very similar then it'll be difficult to tell them apart. Hopefully a large number of users will see their setup fixed and the remaining ones can target the screen locker / Plasma theme issue in a targeted way.

I have not yet applied the patch,b ut added the debug clause to systemd unit.
This happend when locking, then waiting some time, switching VT switiching back.

Mar 09 19:58:54 host1 systemd[1695]: Started Powerdevil.
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Currently using activity  "f99da2dc-b775-44af-b39d-950ba2bff747"
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Settings for loaded activity:
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: "InhibitScreenManagement" = QVariant(bool, false)
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: "InhibitSuspend" = QVariant(bool, false)
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Loading profile for plugged AC
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Handle button events action could not check for screen configuration
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil:
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:58:54 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Charge thresholds: start at 0 - stop at 100
Mar 09 19:59:00 host1 plasmashell[2330]: org.kde.plasma.nm.libs: Wireless scan on "wlp4s0" failed: "Scanning not allowed while unavailable"
Mar 09 19:59:04 host1 systemd[1]: dbus-:1.2-org.kde.powerdevil.backlighthelper@7.service: Deactivated successfully.
Mar 09 19:59:04 host1 systemd[1]: dbus-:1.2-org.kde.powerdevil.discretegpuhelper@1.service: Deactivated successfully.
Mar 09 19:59:04 host1 systemd[1]: dbus-:1.2-org.kde.powerdevil.chargethresholdhelper@2.service: Deactivated successfully.
Mar 09 19:59:04 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:06 host1 kscreenlocker_greet[87458]: pam_warn(kde-smartcard:auth): function=[pam_sm_authenticate] flags=0 service=[kde-smartcard] terminal=[<unknown>] user=[11] ruser=[<unknown>] rhost=[<unknown>]
Mar 09 19:59:06 host1 kscreenlocker_greet[87458]: pam_warn(kde-fingerprint:auth): function=[pam_sm_authenticate] flags=0 service=[kde-fingerprint] terminal=[<unknown>] user=[11] ruser=[<unknown>] rhost=[<unknown>]
Mar 09 19:59:10 host1 plasmashell[2330]: org.kde.plasma.nm.libs: Wireless scan on "wlp4s0" failed: "Scanning not allowed while unavailable"
Mar 09 19:59:10 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:11 host1 /usr/lib/gdm-x-session[1866]: (EE) event6  - Logitech USB-PS/2 Optical Mouse: client bug: event processing lagging behind by 1033ms, your system is too slow
Mar 09 19:59:12 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:12 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:12 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:12 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:12 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:15 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:16 host1 root[87508]: ACPI group/action undefined: button/kpenter / KPENTER
Mar 09 19:59:16 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:16 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:16 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:16 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:16 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:17 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:18 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:18 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:18 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:19 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:19 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:20 host1 plasmashell[2330]: org.kde.plasma.nm.libs: Wireless scan on "wlp4s0" failed: "Scanning not allowed while unavailable"
Mar 09 19:59:20 host1 /usr/lib/gdm-x-session[1866]: (EE) event6  - Logitech USB-PS/2 Optical Mouse: client bug: event processing lagging behind by 22ms, your system is too slow
Mar 09 19:59:21 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:21 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:21 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:21 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:22 host1 /usr/lib/gdm-x-session[1866]: (EE) event6  - Logitech USB-PS/2 Optical Mouse: client bug: event processing lagging behind by 254ms, your system is too slow
Mar 09 19:59:23 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:24 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: SYN_DROPPED event - some input events have been lost.
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:24 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:25 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: SYN_DROPPED event - some input events have been lost.
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:26 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:28 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: SYN_DROPPED event - some input events have been lost.
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:28 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2

Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:30 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:32 host1 /usr/lib/gdm-x-session[1866]: (EE) client bug: timer event6 debounce: scheduled expiry is in the past (-463ms), your system is too slow
Mar 09 19:59:32 host1 /usr/lib/gdm-x-session[1866]: (EE) client bug: timer event6 debounce: scheduled expiry is in the past (-359ms), your system is too slow
Mar 09 19:59:32 host1 /usr/lib/gdm-x-session[1866]: (EE) client bug: timer event6 debounce short: scheduled expiry is in the past (-372ms), your system is too slow
Mar 09 19:59:32 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
^[Mar 09 19:59:33 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: SYN_DROPPED event - some input events have been lost.
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:33 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:35 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: SYN_DROPPED event - some input events have been lost.
Mar 09 19:59:35 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: WARNING: log rate limit exceeded (5 msgs per 30s). Discarding future messages.
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  0
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  0
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:35 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Can't contact ck
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: set kbd backlight value:  2
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value:  2
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Keyboard brightness changed!!
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Kbd backlight brightness value max:  2
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "231"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event2  - Power Button: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "144"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event4  - Video Bus: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "216"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event5  - Video Bus: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "97"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event0  - Sleep Button: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "39"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event6  - Logitech USB-PS/2 Optical Mouse: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "36"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event3  - AT Translated Set 2 keyboard: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "215"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event16 - SynPS/2 Synaptics TouchPad: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "218"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event17 - TPPS/2 IBM TrackPoint: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (**) Option "fd" "184"
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) event7  - ThinkPad Extra Buttons: device removed
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) AIGLX: Suspending AIGLX clients for VT switch
Mar 09 19:59:37 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: received VT change event
Mar 09 19:59:37 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: VT changed from 3 to 5
Mar 09 19:59:37 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: active VT is not initial VT, so ignoring
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: ACTIVE SESSION PATH CHANGED: "/org/freedesktop/login1/session/_35"
Mar 09 19:59:37 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Current session is now inactive
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:67
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:70
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:64
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:68
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:71
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:80
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:69
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:81
Mar 09 19:59:37 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got pause for 13:66
Mar 09 19:59:37 host1 acpid[651]: client 1866[1000:1000] has disconnected
Mar 09 19:59:39 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: received VT change event
Mar 09 19:59:39 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: VT changed from 5 to 2
Mar 09 19:59:39 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: active VT is not initial VT, so ignoring
Mar 09 19:59:39 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: ACTIVE SESSION PATH CHANGED: "/"
Mar 09 19:59:39 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Switched to inactive session - leaving unchanged
Mar 09 19:59:40 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: received VT change event
Mar 09 19:59:40 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: VT changed from 2 to 3
Mar 09 19:59:40 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: switched to registered user session, so reaping login screen in 10 seconds
Mar 09 19:59:40 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: deferring previous login screen clean up operation
Mar 09 19:59:40 host1 gdm[758]: GLib: Source ID 290 was not found when attempting to remove it
Mar 09 19:59:40 host1 gdm[758]: Gdm: GdmLocalDisplayFactory: active VT is not initial VT, so ignoring
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 13:67
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 13:70
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 13:64
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 13:68
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 13:71
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) systemd-logind: got resume for 226:1
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) Open ACPI successful (/var/run/acpid.socket)
Mar 09 19:59:40 host1 /usr/lib/gdm-x-session[1866]: (II) AIGLX: Resuming AIGLX clients after VT switch
Mar 09 19:59:40 host1 acpid[651]: client connected from 1866[1000:1000]
Mar 09 19:59:40 host1 acpid[651]: 1 client rule loaded
Mar 09 19:59:40 host1 wireplumber[2497]: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed?
Mar 09 19:59:40 host1 wireplumber[2497]: PipeWire's BlueZ SPA missing or broken. Bluetooth not supported.
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: ACTIVE SESSION PATH CHANGED: "/org/freedesktop/login1/session/_33"
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Current session is now active
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Currently using activity  "f99da2dc-b775-44af-b39d-950ba2bff747"
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Settings for loaded activity:
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: "InhibitScreenManagement" = QVariant(bool, false)
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: "InhibitSuspend" = QVariant(bool, false)
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil: Loading profile for plugged AC
Mar 09 19:59:40 host1 org_kde_powerdevil[87407]: org.kde.powerdevil:

@Jakob Petsovits new piece of info: when "turn off screen" setting in Energy saving is enabled, screen locking works as intended (meaning no black screen). I've tried playing with "when locked, turn screen off" values and it had no effect, even the ones under 15 seconds still didn't manage to trigger the bug. Is it the same for the others affected?

(In reply to pmargeti34 from comment #46)
> @Jakob Petsovits new piece of info: when "turn off screen" setting in Energy
> saving is enabled, screen locking works as intended (meaning no black
> screen). I've tried playing with "when locked, turn screen off" values and
> it had no effect, even the ones under 15 seconds still didn't manage to
> trigger the bug. Is it the same for the others affected?

Thank you. This matches what I saw in the code. The bug is caused specifically by the turn-off action *not* being enabled and its settings not being read, but the screen locker activation causes the code to run anyway and uses an invalid (negative, immediate) timeout instead of ignoring the activation. Wake-up from sleep is also affected in the same way.

You should be able to avoid this bug by turning on "When locked, turn screen off" with any duration of your choice, until the next release (hopefully) picks up the fix. At that point (hopefully in 6.0.2) disabling the automatic screen turn-off should work again as intended. That's assuming you're not running into any other bugs.

I'm having same issue, but I found strange behavior: I have screen edges enabled to show overview. When I lock the screen and blindly enter the password, the screen flashes and turns black again. However, if you move the cursor to the edge, the screen is became visible, but if you exit overview, everything turns black again.

This issue only appears in X11.

From "About system":

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 580 Series
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B450 AORUS M

(In reply to Jakob Petsovits from comment #44)
> Not sure how best to deal with bug reports because ideally we'd have two
> separate ones, but if the symptoms are indeed very similar then it'll be
> difficult to tell them apart. Hopefully a large number of users will see
> their setup fixed and the remaining ones can target the screen locker /
> Plasma theme issue in a targeted way.

I have created a separate bug report (https://bugs.kde.org/show_bug.cgi?id=483163) for the breeze style + kscreenlocker issue. Not an urgent one to fix imho as I can simply switch to Breeze Light for now to mitigate issue.

Git commit be2b83615d879549ecf9a47b66dc66887419a2dc by Jakob Petsovits.
Committed on 12/03/2024 at 03:47.
Pushed by nicolasfella into branch 'master'.

actions/dpms: Ignore turn-off triggers when action is disabled

Early Plasma 6.0 releases saw many people reporting unintentional
screen turn-off when the screen locker activates/deactivates,
and when the system wakes up from sleep. On X11, this was visible
to the user immediately, whereas on Wayland it spammed system logs
with warnings of invalid -1 idle timeout registrations.

Ironically, this behavior would occur specifically when the DPMS
action (a.k.a. "When locked, turn screen off") was disabled.

The reason is that the DPMS object gets created either way, and
sets up its screen locker activation change handler as well as
suspend/resume handlers in the constructor. But timeout values
can remain invalid until the action is loaded/enabled and
timeout values are populated from profile settings.
Using invalid timeouts in these handlers caused this headache.

This bug was introduced by commit c58085b4, which fixed a bunch of
things, bug also removed checks for invalid timeout values.
Turns out we still need some kind of checks.

We now prevent bad timeout registrations by interpreting negative
values in m_idleTimeoutWhenUnlocked as "idle timeout disabled".
Checks for this value ensure that registerIdleTimeout() is only
called when the action is loaded, regardless of whether it's
triggered by screen locker changing its activation status,
resume after suspend, or any other event.

Alternatively, we could have also moved some signal connections
into loadAction() and disconnected them in onProfileUnload().
Checking on every registration call seems more robust though.
Related: bug 482077

M  +24   -10   daemon/actions/bundled/dpms.cpp
M  +1    -0    daemon/actions/bundled/dpms.h

https://invent.kde.org/plasma/powerdevil/-/commit/be2b83615d879549ecf9a47b66dc66887419a2dc

Git commit a150b9fa622b71420d3c231eb87be695d3f96483 by Nicolas Fella, on behalf of Jakob Petsovits.
Committed on 12/03/2024 at 11:15.
Pushed by nicolasfella into branch 'Plasma/6.0'.

actions/dpms: Ignore turn-off triggers when action is disabled

Early Plasma 6.0 releases saw many people reporting unintentional
screen turn-off when the screen locker activates/deactivates,
and when the system wakes up from sleep. On X11, this was visible
to the user immediately, whereas on Wayland it spammed system logs
with warnings of invalid -1 idle timeout registrations.

Ironically, this behavior would occur specifically when the DPMS
action (a.k.a. "When locked, turn screen off") was disabled.

The reason is that the DPMS object gets created either way, and
sets up its screen locker activation change handler as well as
suspend/resume handlers in the constructor. But timeout values
can remain invalid until the action is loaded/enabled and
timeout values are populated from profile settings.
Using invalid timeouts in these handlers caused this headache.

This bug was introduced by commit c58085b4, which fixed a bunch of
things, bug also removed checks for invalid timeout values.
Turns out we still need some kind of checks.

We now prevent bad timeout registrations by interpreting negative
values in m_idleTimeoutWhenUnlocked as "idle timeout disabled".
Checks for this value ensure that registerIdleTimeout() is only
called when the action is loaded, regardless of whether it's
triggered by screen locker changing its activation status,
resume after suspend, or any other event.

Alternatively, we could have also moved some signal connections
into loadAction() and disconnected them in onProfileUnload().
Checking on every registration call seems more robust though.
Related: bug 482077
(cherry picked from commit be2b83615d879549ecf9a47b66dc66887419a2dc)

M  +24   -10   daemon/actions/bundled/dpms.cpp
M  +1    -0    daemon/actions/bundled/dpms.h

https://invent.kde.org/plasma/powerdevil/-/commit/a150b9fa622b71420d3c231eb87be695d3f96483

Some times I am unable to unlock the session. I have to use loginctl from a VT. The screen locker displays just an unlock button that doesn't do anything. Is it related?

https://i.imgur.com/XuVBJCn.jpeg
https://i.imgur.com/tNbrYJc.jpeg

Confirming fixed in Plasma 6.0.2

That's different; please open a new bug report for it.

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

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

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

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

Whenever lock screen is triggered and I hit Esc in order to show input password field - screen becomes black like it used to before mentioned fix.
Happens on latest Plasma 6.0.2 under X11

(In reply to Tony from comment #59)
> Whenever lock screen is triggered and I hit Esc in order to show input
> password field - screen becomes black like it used to before mentioned fix.
> Happens on latest Plasma 6.0.2 under X11

Esc in the screen locker is the key assigned to turning the screen off. When it's already turned off, a second press of Esc or any other key should turn the screen back on and show the password input field.

Could you go into detail about how the behavior differs from this expected behavior on your system? Ideally create a new bug because we don't want this thread to become a collection for all things related to screens turning off, just the screen turning off when the screen locker activates.

(In reply to Jakob Petsovits from comment #60)
> Esc in the screen locker is the key assigned to turning the screen off. When
> it's already turned off, a second press of Esc or any other key should turn
> the screen back on and show the password input field.
> 
> Could you go into detail about how the behavior differs from this expected
> behavior on your system? Ideally create a new bug because we don't want this
> thread to become a collection for all things related to screens turning off,
> just the screen turning off when the screen locker activates.

Oh, my bad - I wasn't aware of such behavior. Thanks for the clarification!

I saw this happen this evening on 6.0.3 (Tumbleweed 20240328, X11, nvidia 550.54).  After returning to my PC, the lock screen was blank, but the arrow cursor was moveable.  I used alt-ctrl-f1 to a console and then "loginctl unlock-session N" as a workaround.  It seems to be happening about one time in ten.

More interestly this also happened to another desktop in the home which is still on KDE5. On this other KDE5 based PC it's been happening much less often, perhaps once a month.  Could the origin of this bug be something that has been lurking since KDE5 but changes have now caused it to occur more frequently?