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.
I just made an interesting observation. A couple of days ago I added a second monitor to my system. Since then the bug had disappeared. I would always see the lock screen as intended. Today I checked what happens when I remove the second monitor again. I unplugged the second monitor from the computer, changed “/etc/X11/xorg.conf.d/10-monitor.conf” back to what it was before, and rebooted. The bug was back. I would see a black lock screen with the exception of a visible mouse cursor. I then plugged the (second) monitor cable back into the computer, but did NOT connect the other end to the monitor yet. Bug still there. I then connected the other end of the cable to the monitor, and - without having to reboot (!) - the lock screen would then work as intended. The monitor was connected to power, but in standby at that point. When I turned it completely on nothing was visible, it wasn’t even getting a signal. “xrandr -q” was showing the monitor as connected though. I then unplugged the monitor cable from the computer again. The lock screen would still work as intended. So, to sum it up: As long as I connect a second monitor at any time after a reboot, the lock screen will work as intended until the next reboot. The monitor does NOT have to stay connected. It just had to be there at some point. For information: My primary monitor is connected via DisplayPort. The second one is connected via HDMI.
Confirmed for Plasma 6.0.90 KDE Plasma Version: 6.0.90 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.10.0-rc2-1 (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics
*** Bug 487495 has been marked as a duplicate of this bug. ***
Same bug here on Arch. Made a discovery though: When i set the screen to automatically turn off/sleep after a certain amount of time and "wake it up" later. The Bug is not present. And it wont come back as long as i don't reboot. I then can lock the screen just fine using super + L.
Still observing this bug. My description: *sometimes* (almost every time, but not always) after the monitor turns off for inactivity and the session is automatically locked, moving the mouse makes the monitor to turn on, but its completely black. The mouse cursor *is visible* and moves around. My temporary solution: switching to another virtual terminal then back restores the unlock screen. Ctrl+Alt+F2 for example, then Ctrl+Alt+F1, where my X Server lives. This generates this action on Xorg: (II) AIGLX: Suspending AIGLX clients for VT switch Unlock with *black screen* only one message from ksmserver: Jun 23 17:32:09 sertan ksmserver[871275]: qrc:/qt/qml/org/kde/breeze/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed Unlock with *working unlock screen* the same message but then something more: Jun 23 18:58:39 sertan ksmserver[924189]: qrc:/qt/qml/org/kde/breeze/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed Jun 23 18:58:40 sertan ksmserver[924189]: QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) Jun 23 18:58:40 sertan ksmserver[924189]: QMetaObject::invokeMethod: No such method ScreenLocker::AccessDeniedNetworkReply::error(QNetworkReply::NetworkError) Jun 23 18:58:40 sertan ksmserver[924189]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/MediaControls.qml:31:13: QML QQuickImage: Blocked request. Plasma 6.1.0 on X.Org X Server 1.21.1.13 Frameworks 6.3.0 Qt 6.7.2 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) With any theme: Breeze, Breeze Dark (my default), etc...
Another black screen unlock: giu 23 19:59:21 sertan ksmserver[926417]: qrc:/qt/qml/org/kde/breeze/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed giu 23 20:26:50 sertan wireplumber[18136]: wp-device: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed? giu 23 20:26:50 sertan wireplumber[18136]: s-monitors: PipeWire's BlueZ SPA plugin is missing or broken. Bluetooth devices will not be supported. giu 23 20:26:50 sertan wireplumber[18136]: wp-device: SPA handle 'api.bluez5.midi.enum' could not be loaded; is it installed? giu 23 20:26:50 sertan wireplumber[18136]: s-monitors: PipeWire's BlueZ MIDI SPA missing or broken. Bluetooth not supported. giu 23 20:26:50 sertan wireplumber[18136]: pw.resource: can't create node: No such file or directory giu 23 20:26:50 sertan wireplumber[18136]: wp-node: failed to create node from factory 'spa-node-factory' giu 23 20:26:50 sertan wireplumber[18136]: s-monitors: Failed to create BLE MIDI server. giu 23 20:26:50 sertan kded6[926547]: Initializing "/usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.so" giu 23 20:26:50 sertan kded6[926547]: Initializing "/usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_touchpad.so" giu 23 20:26:50 sertan kded6[926547]: kcm_touchpad: Using X11 backend
I think I'm finally able to reproduce: the black screen happens only when the multimedia controls for some video or audio stream are shown in the unlock screen. No multimedia: no problem Multimedia shown with icon and play button, stop, etc...: black screen I'm using PipeWire+WirePlumber
(In reply to at.tarf from comment #39) > I think I'm finally able to reproduce: the black screen happens only when > the multimedia controls for some video or audio stream are shown in the > unlock screen. No, just tested it. It doesn't matter.
This can be fixed by restarting the monitor in a screen-locked (black screen) state. After restarting the monitor, the lockscreen's background image will return and it will not go black again when locking the screen, no matter how or when, until the system is rebooted. (In my case)
I often turn off the monitor manually when going away from the computer. I'll check if turning it off then on again changes something when blank.
Ctrl+Alt+Canc restored the login prompt after a blank lock, triggering the suspend, restart, turn off, etc... screen
Same issue here running MANJARO stable
Same issue here running MANJARO stable, including the observation including (In reply to Karl Gustav from comment #36)
(In reply to Michael from comment #45) > Same issue here running MANJARO stable, including the observation from > (IKarl Gustav, comment #36)
Hello, I have this issue as well, on compiled-from-source kscreenlock 6.1.2 compiled via Arch's PKGBUILD, on an Intel system running hybrid NVIDIA graphics. Same symptoms as discussed previously: - Black screen with a cursor that does not change after locking manually or after timeout - Normal expected behavior from kscreenlock_greet --testing even in Breeze Plasma Style - Switching to a virtual console and back returns the UI - Entering the unlock password results in an unlock, even with no visible widgets - No error messages in logs - Using a Plasma Style other than Breeze works Also, running in an environment where QT_LOGGING_RULES is set: > export QT_LOGGING_RULES="qt.qpa.*.debug=true" results in the expected behavior with a visible lock screen - I was attempting to collect Qt logs with and without a broken lock screen. Enabling logging for qt.scenegraph.* (or anything else at that level I've tried so far) does not "fix" the issue. Maybe this is a race condition after all.
I see this issue related to [Bug 477738](https://bugs.kde.org/show_bug.cgi?id=477738), as I have it either on Wayland and X11 using an AMG-GPU.
Has there really be no update on this. It's pretty annoying. Any workaround would also be appreciated.
Created attachment 173207 [details] attachment-1543339-0.html The workaround is in commet 4: <https://bugs.kde.org/show_bug.cgi?id=483163#c4> This certainly solved the issue for me. I'm not sure the root cause has been fixed. Best Serge On 1 September 2024 17:11:12 UTC, Karl Gustav <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=483163 > >--- Comment #49 from Karl Gustav <kotversuchung@gmail.com> --- >Has there really be no update on this. It's pretty annoying. Any workaround >would also be appreciated. > >-- >You are receiving this mail because: >You are on the CC list for the bug.
*** Bug 492592 has been marked as a duplicate of this bug. ***
... also still there on Gentoo, Plasma v6.1.4. After reading comment #4 I try to switch the theme, hopefully that workaround works.
It seems that if you receive a notification while being in a presence of a black lock screen, the moment you receive a notification, the lock screen fixes itself and renders normally (e.g. normal lock screen with the background and stuff). At least until you lock it again. You could try reproducing this by running the shell command: $ sleep 10; notify-send "My name is bash and I rock da house" and when you hit enter, quickly lock the screen and wait for it to send you a notification. I'm running arch OS: Arch Linux x86_64 Kernel: 6.10.7-arch1-1 Plasma 6.1.4 Theme: Breeze-Dark [GTK2], Breeze [GTK3] Icons: breeze-dark [GTK2/3] If it works only on my machine, then it's a shame
(In reply to Claus-Justus Heine from comment #52) > ... also still there on Gentoo, Plasma v6.1.4. After reading comment #4 I > try to switch the theme, hopefully that workaround works. Using breeze-twilight does not help. Sometimes it helps to wildly switch the monitors on and off and on and off and on and off and on and off and on ...
(In reply to duha.bugs from comment #4) > 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. the workaround works here too (In reply to Daniel Duris from comment #29) > 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. can reproduce, but the screen stays black after ESC is pressed (until the the password is typed while the screen is black)
(In reply to bjoel2 from comment #53) > It seems that if you receive a notification while being in a presence of a > black lock screen, the moment you receive a notification, the lock screen > fixes itself and renders normally (e.g. normal lock screen with the > background and stuff). At least until you lock it again. > > You could try reproducing this by running the shell command: > $ sleep 10; notify-send "My name is bash and I rock da house" > and when you hit enter, quickly lock the screen and wait for it to send you > a notification. > > I'm running arch > OS: Arch Linux x86_64 > Kernel: 6.10.7-arch1-1 > Plasma 6.1.4 > Theme: Breeze-Dark [GTK2], Breeze [GTK3] > Icons: breeze-dark [GTK2/3] > > If it works only on my machine, then it's a shame It works also on my machine :-) EndeavourOS Plasma 6.2.0 Kernel 6.11.3-arch1-1 X11 Breeze Dark
It works fine again since Plasma 6.2.0: Operating System: Manjaro Linux KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.6.54-2-MANJARO (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics Graphics Processor: AMD Radeon Graphics
Are you folks saying that the workaround is no longer required on Plasma 6.2? It's working normally now?
(In reply to Nate Graham from comment #58) > Are you folks saying that the workaround is no longer required on Plasma > 6.2? It's working normally now? In my post from today I just wanted to say that the notify-send trick from bjoel2 works. I have this lock screen issue since yesterday where I upgraded fron 6.1 to 6.2 via pacman. I can blindly enter my password to log in and get back to the desktop.
The bug persists on my system. Operating System: Arch Linux KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.3 Graphics Platform: Wayland
Well, I don't know what's going on - but for the last two days upon arising and turning on the monitor on my main system - which does have the lock screen enabled after 60 minutes being idle, so I have to sign in firs thing in the morning - the system did not turn itself off and came up already logged in! System suspend is not on, because as I said back in March on this bug report, I manually turn off the machine at night. Power management is not on as it's a desktop. So suddenly my system no longer locks itself after 60 minutes. This is on openSUSE Tumbleweed 20241009, the current update.
I'm also able to reproduce this problem on my system just using Meta + L shortcut The issue could fix by itself, if some app will update the screen content. I used DISPLAY=:0 xrefresh entered from the ssh - it refreshes the screen and I'm able to see kscreenlocker greeter after. I also tinkered the source code of kscreenlocker, this short patch also solves the issue for me(but it might break something else): diff --git a/x11locker.cpp b/x11locker.cpp index 577ee9c..28e2a82 100644 --- a/x11locker.cpp +++ b/x11locker.cpp @@ -85,7 +85,7 @@ void X11Locker::initialize() void X11Locker::showLockWindow() { - m_background->hide(); + m_background->show(); // Some xscreensaver hacks check for this property const char *version = "KDE 4.0"; Operating System: Gentoo amd64 KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Graphics Platform: X11
*** Bug 493883 has been marked as a duplicate of this bug. ***
*** Bug 495520 has been marked as a duplicate of this bug. ***
This is bad enough that I'm raising the priority again despite it being X11-only.
I can confirm this bug as well, here are my details: Operating System: Void KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.6.58_1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 8700G w/ Radeon 780M Graphics Memory: 30.4 GiB of RAM Graphics Processor: AMD Radeon Graphics I've had this happen on Mesa versions 24.2.4 and 24.2.6. I am using an HDMI display. Seems to happen most often when using the "Breeze (Follows color scheme)" style although I've had it occur on "Breeze Dark" as well. (The OP says Breeze Dark/Breeze Light works correctly 100% of the time but I disagree, I experience this regardless of chosen style.) The only thing that works 100% of the time is switching between Plasma Styles which fixes the problem temporarily. Switching to tty and back to X11 will also fix it for a single occurrence.
*** Bug 495954 has been marked as a duplicate of this bug. ***
*** Bug 494908 has been marked as a duplicate of this bug. ***
I confirm the issue, lock screen with a black screen and a cursor on the light and dark theme of Breeze, but you can enter a password into a blind. Operating System: Opensuse Tumblewhed 20241114 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.7 Graphics Platform: X11 Graphics Processor: Intel + Nvidia (hybrid)
A temporary solution is to choose a Breeze Twilight, change the color of the windows and the plasma style, turning the theme into light or dark.
Hi KDE team. What is the status of this issue? It has been opened for months, tons of people are experiencing it (just google plasma black screen login - it's on every distro forum, tons of posts on reddit, people switching from KDE because of it); and it is not a nuisance, it is experience-breaking thing (at least for me - I have to close all programs and files and logout to SDDM every evening, and reopen everything every morning, since I am unable to use sleep function). Do you know the reason and it is hard to fix? Can't you reproduce it? If so, can I help you with that? Produce some logs/dumps, since I can reliably reproduce it 100% of time by simply sleeping my pc? No one contacted me about it, just immediately closed my bug report as duplicate, and nothing is happening. (I am writing here, since my bug https://bugs.kde.org/show_bug.cgi?id=495954 was immediately closed as duplicate of this one, despite being somewhat different [black login screen only after sleep, regardless of theme] and I am not sure anyone is even reading comments on closed bugs)
@Roman Have you tried entering your password blind? That is a sufficient work-around for me, and I do not have to shut down and restart. Also, since I changed themes, I haven not experienced this bug, so that is a possible work-around as well. KDE is a volunteer organization, so this bug will get some love when there is someone with sufficient time and knowledge to tackle this bug. Disclaimer: I'm a user; not a member of KDE.
(In reply to Roman from comment #71) > Do you know the reason and it is hard to fix? Can't you reproduce it? If so, can I help you with that? Speaking just for myself: When I was experiencing this in the past, I tried to figure out the cause of this bug and found it very challenging. Since then, I have occasionally logged into an X11 session instead of my regular Wayland session, and have not been able to reproduce it anymore. I think it's going to be next to impossible for a developer to solve if they can't reproduce it on their own system. If I were still able to reproduce it here, I would want to look into the difference between testing mode (`kscreenlocker_greet --testing`), which did not ever exhibit this issue for me, and regular (X11) screen-locking mode, which did exhibit the issue. I wonder if perhaps the (necessary) Qt::X11BypassWindowManagerHint flag that's set in greeterapp.cpp causes some sort of race condition that we don't see in regular X11 or Wayland windows.
That's right. Almost no core Plasma developers use X11 anymore. Speaking personally, I'm in the same boat as Jakob: whenever I log into an X11 session to try to reproduce this, it doesn't happen. I've never had it happen, in fact. We need a 100% reproducible case that makes the issue happen for a developer.
@Joshua "Have you tried entering your password blind?" - Yes, it does nothing. "Also, since I changed themes, I haven not experienced this bug, so that is a possible work-around as well." - I've tried all Breeze themes and Oxygen, happens on all of them @Nate thanks for replying. I would love to switch to Wayland too, but can't for now (for the life of me, I just can't get RDP to windows machines work on wayland without horrible lag/stutter/blur; and that is big part of my work) I am software engineer too (unfortunately far from stack used in plasma), and few times we have reports from wild of issues we just could not reproduce locally, we just gave the client custom build with absurdly detailed logging/tracing, and have him send back logs/dumps. Isn't something like that possible with plasma? I am willing to be guinea pig for this, if it won't break my system. Or is it X11 "unofficialy" unsupported yet, so you don't want to invest in it anymore?
(In reply to Roman from comment #75) > "Have you tried entering your password blind?" - Yes, it does nothing. That's interesting. That may be a different bug, or related to this, but hitting another area in code, then, as I *think* all the conversation in this ticket has been talking about a bug that could be worked around via blind-typing. Another check, just to be sure: when your screen is blank, is your machine still reachable (ssh, or some such). Just want to rule out a full lock-up on resume, which is another bug I've seen before.
I'm also unable to reproduce this with git-master or a regular X11 session on that same machine Both with locking and sleeping the system, the unlock screen works correctly after multiple tests I don't think I've had this happen anytime on this install
@Joshua I've just re-checked it again now just to be sure, and let me rephrase my answer: Blindly typing my password does not solve the issue, but *something* does happen. On login screen, everything is black except mouse cursor, and I can blindly find password box and cursor changes to text-input cursor. After I type in password and press enter, everything stays black, cursor is no longer text-input in that area - so I am on desktop. I can blindly type [Meta]kwrite[enter] and on large part of screen, cursor is again text-input, indicating that indeed kwrite is open. Also, for example, it works when I press volume up/down keys on keyboard, there is sound response indicating volume being set. I can even blindly find volume tray icon and scroll over it to set volume. So whole plasma is "there", just nothing except mouse cursor is visible. PC responds to ping from other machine whole time (login screen, and after).
(In reply to Roman from comment #78) > @Joshua > I've just re-checked it again now just to be sure, and let me rephrase my > answer: Blindly typing my password does not solve the issue, but *something* > does happen. On login screen, everything is black except mouse cursor, and I > can blindly find password box and cursor changes to text-input cursor. After > I type in password and press enter, everything stays black, cursor is no > longer text-input in that area - so I am on desktop. I can blindly type > [Meta]kwrite[enter] and on large part of screen, cursor is again text-input, > indicating that indeed kwrite is open. Also, for example, it works when I > press volume up/down keys on keyboard, there is sound response indicating > volume being set. I can even blindly find volume tray icon and scroll over > it to set volume. So whole plasma is "there", just nothing except mouse > cursor is visible. PC responds to ping from other machine whole time (login > screen, and after). That's a different bug then.