SUMMARY When activating lock screen (via shortcut, menu option or timer), the screen becomes blank. The screen is not turned off and maintains the backlight on, but nothing is drawn on screen. Cursor can be seen when moved, and password can be blindly typed to return into desktop, which becomes immediately visible again. Also, when the lock screen is blank like this, switching to another virtual terminal and returning to the lock screen vt will cause it to be displayed correctly. This behavior only occurs when Breeze is selected as plasma style, and it happens most of the time. Switching to Breeze Light, Breeze Dark or Oxygen will result in the lock screen being displayed correctly 100% of the time. Switching back to Breeze will cause the wrong behavior again. Please note that this bug is separate from https://bugs.kde.org/show_bug.cgi?id=481308 which is powerdevil-related and causes the screen to turn off. Energy settings make no difference for this issue, the screen is still on but blank. The difference to behaviour seems to be made by changing the plasma style. STEPS TO REPRODUCE 1. Use Breeze as plasma style 2. Activate lock screen using keyboard shortcut, launcher option or wait for it to be activated by inactivity 3. 19 times out of 20, the lock screen will be blank, even if the screen is turned on OBSERVED RESULT Blank screen, with the screen turned on. Moving cursor around makes it visible. EXPECTED RESULT Lock screen window correctly drawn. SOFTWARE/OS VERSIONS 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-arch1-1 (64-bit) 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 ADDITIONAL INFORMATION Speculation: one notable difference between Breeze and the other plasma styles (Breeze Light, Dark, etc.) is that Breeze is the only style that is designed to follow the user-chosen color scheme. So it is possible that color scheme implementation in plasma is playing a role into the issue. I have tried changing the color scheme (i.e., using the one from wallpaper or the default one) but changing the scheme itself makes no difference. The issue only seems to occur with the screen locker and I have not seen it anywhere else in plasma.
Does it happen on Wayland too, or only X11?
This happens for me on my laptop too. X11 session (because nvidia). 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: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 31,0 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20L5CT01WW System Version: ThinkPad T480 NOTE: Switchable nvidia/intel graphics. NVIDIA GeForce MX150. I'm running in hybrid mode (which doesn't work on Wayland).
Actually there is one difference, when my screen is black (but on, backlight still on) I don't see a cursor either.
I can reproduce the issue on X11. A workaround that works for me is: Switch Plasma Style to either Breeze Dark or Breeze Light Once I select Breeze (Follows color scheme) I can reproduce the issue again.
(In reply to Nate Graham from comment #1) > Does it happen on Wayland too, or only X11? It only occurs with X11 for me. Tested this evening with Wayland and Breeze plasma style, did not manage to reproduce; when activating the screen locker in wayland, the screen consistently behaves by going blank for a half second first, and then displaying the lock screen correctly.
Ah, this should have been fixed in Plasma 6.0.2, then. Can you test that and re-open if it's still broken?
I still see this on 6.0.2. Just installed it on Arch Linux, rebooted and then tested it. I have a weird observation to add though. While most times the lock-screen is not visible (but the mouse cursor is), sometimes I did actually see the lock-screen. I keep my computer on overnight, but the session is locked and the monitor is turned off. On most occasions in the morning the lock-screen was visible. I also had that happen once during the day. It only seems to happen when a couple of hours have passed. And what may be a factor here (though I'm not sure) is that a lot of disk activity happened while the session was locked or just before it was locked. My computer does automatic backup overnight. And the one time when it worked during the day, I had copied a couple of gigabytes to a USB disk just before locking the session.
This black screen bug just happened, as soon as the screen goes off and I move the mouse the plasma wakes up and then the screen goes black, I need to use KDE COnnect or TTY in arch linux to unblock the session
(In reply to Nate Graham from comment #6) > Ah, isso deveria ter sido corrigido no Plasma 6.0.2, então. Você pode > testar isso e reabrir se ainda estiver quebrado? I updated Arch linux with plasma 6.0.2, and this black screen bug still happens Nate.
(In reply to Nate Graham from comment #6) > Ah, this should have been fixed in Plasma 6.0.2, then. Can you test that and > re-open if it's still broken? Just tested on Arch with plasma 6.0.2 and it still occurs for me. I also confirmed same behaviour as reported initially: only occurs with plasma style set to Breeze and only on X11, switching to another plasma style such as Breeze Light will prevent the issue from occurring. Does not occur with Wayland.
(In reply to Giacomo Lozito from comment #10) > (Em resposta a Nate Graham no comentário nº 6 ) > > Ah, isso deveria ter sido corrigido no Plasma 6.0.2, então. Você pode > testar isso e > > reabrir se ainda estiver quebrado? > > Acabei de testar no Arch com plasma 6.0.2 e ainda ocorre para mim. > Também confirmei o mesmo comportamento relatado inicialmente: ocorre apenas > com o estilo de plasma definido como Breeze e apenas no X11, mudar para > outro estilo de plasma, como Breeze Light, evitará que o problema ocorra. > Não ocorre com Wayland. It does happen with Wayland, but I'm using the Breeze Dark theme
It must be something within the Breeze theme. As I can also reproduce it on my OrangePi Neo I'm currently working on. As soon as I switch to our own theme Breath, which is based on Breeze, that issue is more or less gone on X11. I will test Wayland later on the device.
Same issue, with Breeze and Breeze Dark on 6.0.2 , X11, Arch. Specifically seems to be an issue specifically with the "Plasma Style" Breeze, not with the entire global breeze theme (or any other components of the global theme). Using "Breeze Dark" global theme, and then switching the Plasma Style to something else, works just fine. The "Breeze Dark" and "Breeze Light" PLASMA styles do appear to work fine though (oddly enough, the "Breeze Dark" Global theme defaults to the regular "Breeze" Plasma style. "Breeze Twilight" Global defaults to the the "Breeze Dark" Plasma, though. Not at all confusing lol). TLDR: Problem is somewhere in the "Breeze" Plasma Style, not the global theme. Also possibly of note, often times after switching the plasma theme (either directly, or using a global theme) to Breeze, it will lock and show the screen just fine, but only the first time. Any subsequent locks show up black again. (since this may be important - I am running a laptop with dual graphics (intel integrated + nvidia) with the nvidia prime driver. seems like other more conventional graphics setups are having this issue too, though)
*** Bug 483371 has been marked as a duplicate of this bug. ***
Same here (EndeavourOS, KDE 6.0.2, X11) In my case, only Breeze or Breeze Twilight works as expected.
Confirmed on openSUSE Tumbleweed desktop (not laptop) latest snapshot as of this date. I'm on X11 after the Obsidian note-taking app does not work at all with Wayland. (By the way, changing to Wayland without asking was a no-no.) I had my system set to not do session suspend at all being on a desktop, but to turn off the screen and lock the screen after 60 minutes. Then I turn off the monitor at night before bed so I can sleep without waiting for the monitor to turn off itself. In the morning I turn on the monitor, wiggle the mouse and get my login screen. But the last couple days - but not EVERY day - the monitor turns on, but the screen is dark and the mouse wiggle does not have any result. Hitting escape turns the screen from gray to absolute black. I then have to switch to a virtual terminal which appears with no problem and I then log in as root and reboot. I've decided to simply switch off screen turnoff to see if that fixes the issue. I always turn off the monitor manually anyway before bed. so why bother with screen turnoff? During the day I'm usually at the machine anyway so screen turnoff is mostly a nuisance if I'm away for more than 60 minutes. Haven't tried switching themes yet to test. Might try that tonight if the Breeze Twilight theme is acceptable (no Dark theme is for me.) It's interesting that I do NOT have the problem on my second desktop which also does not use session suspend but only turns off the screen and locks the screen. Sometimes I forget to turn off that system's monitor so perhaps I just haven't seen the issue yet on that one.
So I turned off "Turn Off Screen" under energy settings. Tonight after I went for a shower and other measures which took longer than 60 minutes, I came back to find the lock screen blank, wiggling the cursor did nothing. I went into virtual terminal 1 and messed around, then tried to go back to the original terminal (F7) but couldn't do it. Then I got this error message which I don't comprehend at all and don't know if it has anything to do with the blank screen issue: localhost login: [112762.275565] [T62483] amdgpu 0000:08:00: [drm: amdgpu_ring_test_helper [amdgpu]] *ERROR ring comp_1.0.1 test failed (-110) [112762.64478211] [T5552] PM: can not get swap writer So enough fooling around, I rebooted. I doublechecked my settings for Session Suspend and Screen Locking. Session Suspend does nothing and the screen is not supposed to be turned off at all. The Screen Lock setting is 60 minutes and that worked - except it's impossible to get back from the blank screen once the mouse is wiggled. The cursor is visible but nothing else. I still haven't tried another theme. For now I'm simply going to turn off Screen Locking because I don't have time for this nonsense.
I can confirm that switching to Breeze Light under Plasma Style removed black locking screen. Switching back to Breeze and black lock screen is immediately back.
(In reply to Daniel Duris from comment #18) > I can confirm that switching to Breeze Light under Plasma Style removed > black locking screen. Switching back to Breeze and black lock screen is > immediately back. Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-26-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Graphics Processor: AMD Radeon Graphics
I enabled some extra logs and encountered this issue (or something that looks exactly like it) on an X11 session today, current newest master of all Plasma session components, as of 2024-03-31. I locked manually using the Meta+L shortcut and got it to remain black once before a correctly painted lock screen, in another session black on a following lock screen after the initial one worked correctly. I posted my logs into a GitLab snippet: https://invent.kde.org/-/snippets/3059 They look roughly alike, no particular differences stick out to me between locks that worked fine and locks that turned black with cursor. Info Center blurb: Operating System: Arch Linux KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.1.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-arch2-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20QD001VUS System Version: ThinkPad X1 Carbon 7th
If it's not a caching issue, and it's not necessarily a race condition, it could also be an issue with invalid memory access somewhere. I decided to run `kscreenlocker_greet --testing` in valgrind to see what it says. Here's the excerpt that should roughly line up with window creation (I forgot to specify more verbose QT_LOGGING_RULES): kf.windowsystem: Loaded plugin "/home/kpetso/build/prefix/lib/plugins/kf6/kwindowsystem/KF6WindowSystemX11Plugin.so" for platform "xcb" kf.coreaddons.kdirwatch: Available methods: QList("Stat", "INotify", "QFileSystemWatcher") preferred= INotify kf.kirigami.platform: Loading style plugin from "/home/kpetso/build/prefix/lib/plugins/kf6/kirigami/platform/KirigamiPlasmaStyle.so" ==10885== Conditional jump or move depends on uninitialised value(s) ==10885== at 0x1D0CD789: ??? ==10885== by 0x218D1E4F: ??? ==10885== Locked at 1711932039 ==10885== Conditional jump or move depends on uninitialised value(s) ==10885== at 0x1D0CD789: ??? ==10885== by 0x1D2D08DF: ??? ==10885== ==10885== Conditional jump or move depends on uninitialised value(s) ==10885== at 0x1D0CD789: ??? ==10885== by 0x2140FF5F: ??? ==10885== kscreenlocker_greet: PamAuthenticators: starting authenticators kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating And after the PAM authentication workers have started, we've got two invalid reads with an actually useful backtrace for which I just created https://bugreports.qt.io/browse/QTBUG-123878. Either I'm stupid and can't read code / valgrind output, or this is actually a non-trivial bug in central Qt code. It's somewhat plausible that our bug is coming from one of these invalid memory accesses. I wish I had an actually useful backtrace for the "Conditional jump" ones too. Not sure why valgrind denies me that one. Missing frame pointers on Arch perhaps? If you have a debug build of kscreenlocker at hand, maybe you can see if your invocation of `valgrind ${KDE_PREFIX}/lib/libexec/kscreenlocker_greet --testing` gives you something more useful than the pasted question marks above.
(In reply to Jakob Petsovits from comment #21) > And after the PAM authentication workers have started, we've got two invalid > reads with an actually useful backtrace for which I just created > https://bugreports.qt.io/browse/QTBUG-123878. Either I'm stupid and can't > read code / valgrind output, or this is actually a non-trivial bug in > central Qt code. Digging a little deeper, it looks like Qt is not broken and I was in the wrong. Bwah. I wonder whether that means we have an issue in KSvg though?
(In reply to Jakob Petsovits from comment #22) > (In reply to Jakob Petsovits from comment #21) > > And after the PAM authentication workers have started, we've got two invalid > > reads with an actually useful backtrace for which I just created > > https://bugreports.qt.io/browse/QTBUG-123878. Either I'm stupid and can't > > read code / valgrind output, or this is actually a non-trivial bug in > > central Qt code. > > Digging a little deeper, it looks like Qt is not broken and I was in the > wrong. Bwah. I wonder whether that means we have an issue in KSvg though? Alright, so I added lots of debug output and tracked down the valgrind warnings past initial app instantiation down to a memory read just slightly past the end of the SVG text that we're decompressing within KSvg. The invalid read is performed by libpcre from within QRegularExpression, reproducible without KDE code entirely, and https://bugreports.qt.io/browse/QTBUG-123892 determined that despite the valgrind warning there is no bug. So we still need to find the real culprit. On the memory side of things, there's only one more valgrind warning left apart from the above, in libxcb as used on app startup by Qt's X11 backend in QXcbConnection::initializeScreensFromMonitor(). *Maybe* that's related. But I've had two duds so far, so don't hold out your hopes too high.
Regardless of what happens, thanks a ton for the exhaustive investigation, Jakob!
Earlier today I went into "System Settings / Display & Monitor" and DISabled "Compositing / Enable on startup". I then rebooted. After I logged back into KDE, I could then activate the lock screen and it would show properly. I tested this multiple times, and it worked fine every time. I then re-enabled the compositor, and then the lock screen would show up black again except for the mouse cursor. So the bug only seems to appear when the compositor is enabled, which makes me wonder if the compositor is getting confused about which window should be displayed on top? If I understand the design of the lock screen correctly (as described in the sources in kscreenlocker/DESIGN), then a fullscreen (empty - all black) window is put on top of all other windows, and then the actual lock screen is put on top of that. If the compositor for some reason would think that that fullscreen window belongs on top of the lock screen... we would see exactly this bug. So, could this actually be a compositor bug?
I am experiencing this bug on KDE Plasma 6 on Garuda Linux on a Lenovo Yoga laptop with an AMD processor. If I toggle the tty, the lock screen works again. In other words: lock (by sleep or manually locking) --> black screen with cursor ---> Ctrl-Alt-F1(screen stays black, cursor is gone)--->Ctrl-Alt-F2--->Lock screen is back and can log in normally. My theme is catppuccin Macchiato teal and my icons are Beautyline.
Getting this one on Arch, Plasma 6.0.4. Changing "Colors & Themes > Plasma Style" to anything other than Breeze... including a theme that is literally just Breeze without a single customization. As in it's a `.local/share/plasma/desktoptheme` folder with just `settings` and `metadata.desktop` and it's pointing to just Breeze itself. User color work fine, too! It's the same thing with a cursor visible, and changing according to the UI elements under it (which is only the text field, everything else uses default pointer on hover...), and typing in blindly works fine. And it sometimes does show up. I tried disabling all the power saving options, nothing changed. Typically have it set with everything on. No blue light filter thing though. Launching `/usr/lib/kcreenlocker_greet` manually with Breeze works fine, with or without `--testing`, it's just the screen locking via a hotkey when it breaks Desktop, X11, single AMD GPU, no iGPU/APU, single screen with 150% scaling and 4K native res.
I don't know if this is related, but I'll sometimes have a black lock screen. But, if I blind-type my password, it unlocks, and displays the desktop without issue. Plasma 6.0.4 on X11
If I press Escape key on properly shown locked screen with Breeze theme, the screen goes blank. I have to juggle bit with a keyboard to get the locked screen displayed again. Maybe related to the comment above.
*** Bug 486250 has been marked as a duplicate of this bug. ***
Here's how it looks with the Show Paint effect enabled: https://streamable.com/nrprsw
I'm getting this on Arch. Can still blind login, and not using breeze solves the problem.