Bug 451386 - Black Screen with Movable Cursor after Screens Resume from Sleep
Summary: Black Screen with Movable Cursor after Screens Resume from Sleep
Status: RESOLVED DUPLICATE of bug 477738
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.24.2
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-11 03:34 UTC by Stephen Ackerman
Modified: 2024-01-17 16:47 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Dmesg log output (527.38 KB, text/x-log)
2022-03-11 03:43 UTC, Stephen Ackerman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Ackerman 2022-03-11 03:34:39 UTC
SUMMARY
When my screens go into standby, it is not possible to wake back up to the login screen. Only a black screen with a cursor is present, in some cases there are duplicate images of the cursor (only one moves).

***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

STEPS TO REPRODUCE
1. Wait for the screen to time-out and power off
2. Move the mouse to wake the screen

OBSERVED RESULT
Black screen with movable cursor. Unable to interact with the login screen or resume the session.

EXPECTED RESULT
See Lock screen, can log in successfully and resume the prior session.

SOFTWARE/OS VERSIONS
KDE Plasma 5.24.2
KDE Frameworks 5.90.0
Qt Version 5.15.2
Kernel Version 5.16.12
Graphics Platform: Wayland
Processor: Ryzen 9 3900X
GPU: RX 6700XT

ADDITIONAL INFORMATION
The Displays are reported in display settings as LG Electronics LG Ultra HD 214473 and LG Electronics LG Ultra HD 183701. They were both scaled to 125%.

I have a very similar issue on X11, where when the screens first wake, they will be blank. After a few moments (and sometimes some flickering) eventually at least one screen will get a locked login page, and I can log in. Often when typing into this login page, it doesn't actually show any characters typing, but it will unlock the screen, at which point normal operation resumes.

I attempted to loginctl unlock-session, it didn't fix the problem. I tried to kill kscreenlocker, and did get the "The screen locker has crashed, run this command to unlock" page, but after running the provided loginctl unlock-session, there was still just a black screen with a cursor.

I attempted to restart SDDM, but it did not seem to result in a usable system. I had to fully reboot.

These screens seem to disconnect to some extent when they go into standby, which I believe is related to the problem. If I move the mouse immediately after the screens go into standby (they display a message for a few seconds) then everything is fine. Once they go into sleep, though, the bug happens.
Comment 1 Stephen Ackerman 2022-03-11 03:43:36 UTC
Created attachment 147434 [details]
Dmesg log output

Dmesg log from around the time of the issue (As well as the system startup in case that provides any useful info)
Comment 2 Stephen Ackerman 2022-03-11 17:38:11 UTC
I was able to capture a video of the screen when this happened again. It seems I can reliably reproduce it, what would be the best way to provide useful information to debug the problem?
Comment 3 Stephen Ackerman 2022-03-13 20:40:17 UTC
I can also reproduce this issue by just turning both displays off.
Comment 4 Chris 2022-03-19 18:16:39 UTC
I'm having a similar issue. When the display goes to sleep or I turn off the monitor, some KDE processes (konversation, kmail, akregator, etc) lock up with 100% CPU utilization, and when I wake/turn on the monitor, I just get a blank screen with a cursor. If I move the cursor, the screen will flicker with dirty contents and leave mouse trails all over the place. Blindly typing in my password apparently does nothing. I have found that I can kill the user (switching to a different tty, e.g. ctrl+alt+f2, kill kwin_wayland and various other processes running as the user) and it'll bring me back to the login screen where I can log back in and use the system again. Better than a full reboot, but hardly makes for a usable system whenever the monitor is turned off.

I have also found that if I set Adaptive sync to Never in System Settings -> Display and Monitor, I can turn off the monitor and turn it back on and keep KWin-Wayland running properly. However the same KDE processes will still lock up with 100% CPU utilization (they become unresponsive and need to be closed/restarted), and the Adaptive sync setting resets to Automatic.

Interestingly, this only started when I got a new monitor. I had an old hand-me-down Samsung monitor connected via HDMI, and never had any issues when the display went to sleep or I turned off the monitor. But once I replaced it with a newer LG 27GP850 monitor connected via Display Port, these issues started.

I'm using Debian Unstable with kde-wayland 5.24.3-1.
Comment 5 Stephen Ackerman 2022-03-19 20:33:47 UTC
Possibly relevant, both of my monitors are connected via Displayport. They both support Freesync, however neither had it enabled initially. Now, one has it enabled., but not the other. I also tested with both having it enabled, but it caused one of them to flicker (suspect a problem with that monitor, not KDE) so I disabled it.

I also have a Valve Index connected to the system via Displayport, if that is relevant.
Comment 6 Stephen Ackerman 2022-04-30 20:24:48 UTC
I'm wondering if this is possibly related to #453042 ?

When kwin_wayland 5.24.5 makes it into Debian, I will re-test.
Comment 7 Christopher W. 2022-05-08 09:27:39 UTC
I also have an LG Monitor connected via HDMI and if i set to Sleep Mode and Wake up with Wayland i get a Cursor and some Applications i used are open but nothing more open. I can switch tty and close the Apps as intended.
Comment 8 Stephen Ackerman 2022-05-20 03:25:02 UTC
Tested with Plasma 5.24.5 as shipped by Debian, same problem.
Comment 9 Christopher W. 2022-06-07 16:08:32 UTC
after some Updates, it disappeared for me. I had no problem for 1-2 weeks now on Arch.
Comment 10 Ta-Lun Yen 2022-06-23 17:57:22 UTC
I also encountered this but it appears to only happen when I scale monitor to 125%.
Comment 11 Stephen Ackerman 2022-06-23 19:22:33 UTC
> I also encountered this but it appears to only happen when I scale monitor to 125%.

That's good to know! My monitors were scaled to 130% as well, because 100% is too small.

I will see if I can re-test this with scaling disabled (100%) and see if it's reproducible under those conditions.
Comment 12 Chris 2022-06-23 20:40:51 UTC
I don't use scaling, and it happens to me (although I haven't tested 5.25 yet).
Comment 13 Stephen Ackerman 2022-06-24 00:54:38 UTC
Debian Testing just updated to Qt 5.15.4 in Testing, an I installed it on my system.

Initial tests (with a 1 minute screen timeout and waiting a few seconds after the screen powered off to wake it back up, as well as power cycling both screens) look promising for the issue possibly being resolved. Plasma appears to have crashed and restarted (one desktop lost the background and went black), but kwin kept running (as well as Firefox, Konsole, and Pavucontrol).

Other distros may have shipped 5.15.4 sooner than Debian, that may be why some (eg Christopher W) aren't experiencing the issue after updates?

I'm going to leave the system for a bit longer, and see if the issue returns.
Comment 14 Stephen Ackerman 2022-06-24 02:55:54 UTC
Some success; coming back to the machine, kscreenlocker had crashed 

> [99933.409250] kscreenlocker_g[154301]: segfault at 200000001 ip 0000000200000001 sp 00007ffcaa20cca8 error 14 in kscreenlocker_greet[5588d5765000+b000]
> [99933.409265] Code: Unable to access opcode bytes at RIP 0x1ffffffd7.

But after flipping to a VT, executing loginctl unlock-session, my Plasma session was still there! Seems this issue might be tied to Plasma on Qt 5.15.2 and 5.15.3 or 5.15.4 might be the fix?
Comment 15 Christopher W. 2022-06-24 19:02:00 UTC
I have expierienced since then one time that issue. It seems not 100% fixed. But it is better than before. I don't know why.
Comment 16 Christopher W. 2022-06-24 19:19:24 UTC
I just updated to QT 5.15.5 now.
Comment 17 Stephen Ackerman 2022-11-09 23:54:06 UTC
With Plasma 5.26.0, Frameworks 5.98.0, and Qt 5.15.6 on Kernel 6.0.7, I have not observed this issue occurring anymore after allowing my screens to sleep multiple times over the last day or two.

After entering my password, the Login screen appears to get stuck with just a "Login" button, and I have to use loginctl unlock-sessions to unlock, but the desktop is still functioning properly afterwards.

Noticed Plasma bugging out a few times (eg black desktop background), but Kwin appears to be stable, so the desktop session continues (And I can 'fix' Plasma by just "plasmashell --replace")
Comment 18 Nate Graham 2022-11-10 15:07:36 UTC
OK great, thanks!

> After entering my password, the Login screen appears to get stuck with just a "Login" button, and I
> have to use loginctl unlock-sessions to unlock, but the desktop is still functioning properly afterwards.
That would be a separate bug in KScreenLocker, probably Bug 456210.

> Noticed Plasma bugging out a few times (eg black desktop background), but Kwin appears to be
> stable, so the > desktop session continues (And I can 'fix' Plasma by just "plasmashell --replace").
Yeah this this is still another bug, probably one of the many consequences of Bug 450068.
Comment 19 Nate Graham 2024-01-17 16:47:55 UTC

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