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

When I was with someone who could reproduce it was determined that the window from X11Locker::m_background window was for some reason stacked above the lockscreen even though it did not have focus.

(In reply to Andreas from comment #70)
> 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.

This works for me on Arch Linux, thank's.

(In reply to Nate Graham from comment #74)
> 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.

I can always confirm and reproduce this bug on Fedora 41. The lock screen always turns black when I set the Plasma style to Breeze.
If I change the style from Breeze to Breeze dark or another style, the lock screen works as expected.

(In reply to Attila from comment #83)
> (In reply to Nate Graham from comment #74)
> > 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.
> 
> I can always confirm and reproduce this bug on Fedora 41. The lock screen
> always turns black when I set the Plasma style to Breeze.
> If I change the style from Breeze to Breeze dark or another style, the lock
> screen works as expected.

Oh, sorry, I forgot to say that I am on X11. I think this is important.

(In reply to David Edmundson from comment #80)
> When I was with someone who could reproduce it was determined that the
> window from X11Locker::m_background window was for some reason stacked above
> the lockscreen even though it did not have focus.

I also found this behavior. I made patched version of kscreenlocker for my usage(patch included in comment 62, or you can just call raise() on m_background in x11locker.cpp when background window is shown). It works for me. Seems like bug was introduced somewhere inside Qt6.

(In reply to Andrii R. from comment #85)
> (In reply to David Edmundson from comment #80)
> > When I was with someone who could reproduce it was determined that the
> > window from X11Locker::m_background window was for some reason stacked above
> > the lockscreen even though it did not have focus.
> 
> I also found this behavior. I made patched version of kscreenlocker for my
> usage(patch included in comment 62, or you can just call raise() on
> m_background in x11locker.cpp when background window is shown). It works for
> me. Seems like bug was introduced somewhere inside Qt6.

Patch also works for me on Fedora 41.

Patched kscreenlocker-6.2.4 for Fedora 41
https://koji.fedoraproject.org/koji/taskinfo?taskID=126540135

If it works, we should consider it upstreaming it. Andrii, would you be interested in submitting it at https://invent.kde.org/plasma/kscreenlocker/-/merge_requests?

So what will happen when 'm_background->lower();' from the function 'void X11Locker::hideLockWindow()' gets removed? 'm_background->shown' we have in 'bool X11Locker::nativeEventFilter' and 'void X11Locker::addAllowedWindow'. So if we don't lower it we also don't need to raise it.

Hmm, via the 'X11Locker::hideLockWindow()' function m_background gets lowered. Maybe the 'X11Locker::showLockWindow()' needs the same treatment with Qt6? https://invent.kde.org/philmmanjaro/kscreenlocker/-/commit/02f5059c1eeb27038a138374ae52517c30eb2c27

Git commit 2d258e6c72d4c08d5ff01c92ff6e954b34b3ebe6 by Fushan Wen, on behalf of Philip Müller.
Committed on 12/12/2024 at 07:07.
Pushed by fusionfuture into branch 'Plasma/6.2'.

x11locker: lower m_background when hiding

X11Locker::m_background window was for some reason stacked above the lockscreen, even though it did't had focus. Bug seems to be introduced by Qt6. 

M  +1    -0    x11locker.cpp

https://invent.kde.org/plasma/kscreenlocker/-/commit/2d258e6c72d4c08d5ff01c92ff6e954b34b3ebe6

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

Git commit 2b798ffdce47a5175c67b4e7dfca4e3a7b57385d by Fushan Wen.
Committed on 12/12/2024 at 07:07.
Pushed by fusionfuture into branch 'master'.

x11locker: lower m_background when hiding

X11Locker::m_background window was for some reason stacked above the lockscreen, even though it did't had focus. Bug seems to be introduced by Qt6. 


(cherry picked from commit 2d258e6c72d4c08d5ff01c92ff6e954b34b3ebe6)

02f5059c x11locker: lower m_bacckground when hiding

Co-authored-by: Philip Müller <philm@manjaro.org>

M  +1    -0    x11locker.cpp

https://invent.kde.org/plasma/kscreenlocker/-/commit/2b798ffdce47a5175c67b4e7dfca4e3a7b57385d

With kscreenlocker-6.2.5 black screen still appears randomly.
With kscreenlocker-6.2.4 and patch from comment 62 black screen never showed up.

kscreenlocker-6.2.5 is identical to kscreenlocker-6.2.4 with the patch applied; there are no other changes apart from translations. I suspect what you're seeing is in fact a different issue.

Changes between  kscreenlocker-6.2.4/x11locker.cpp and kscreenlocker-6.2.5/x11locker.cpp are not the same as patch from comment 62:

void X11Locker::showLockWindow()
 {
     m_background->hide();
+    m_background->lower();
.
     // Some xscreensaver hacks check for this property
     const char *version = "KDE 4.0";

patch from comment 62:

 void X11Locker::showLockWindow()
 {
-    m_background->hide();
+    m_background->show();

     // Some xscreensaver hacks check for this property
     const char *version = "KDE 4.0";

I believe I am still experiencing this after updating to Plasma 6.2.5 - when on the "Breeze (follows color scheme)" style, my screenlocker is a blank black screen with cursor visible. Unlocking blindly works fine.

Switching to "Breeze Dark" style mostly avoids the issue. On either style the issue is not reproducible 100% consistently but it's much more common on "Breeze (follows color scheme)".

Operating System: Void 
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.7_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

So, this bug should be reopened?

Count me in as another one for whom 6.2.5 does NOT fix this bug.

I vote to reopen this bug.

One more, the bug is not fixed.

The idea was to use the hide / lower function, as this was the case reported. Sure, the show function seems to fix it properly, but it was not clear if that regressed in other places. Did those who are affected tried the original fix proposed here?

Based on the feedback we went with: https://invent.kde.org/plasma/kscreenlocker/-/commit/2d258e6c72d4c08d5ff01c92ff6e954b34b3ebe6

Proposed fix on current feedback:

```
--- a/x11locker.cpp	2025-01-05 09:38:34.380078537 +0700
+++ b/x11locker.cpp	2025-01-05 09:39:17.740078945 +0700
@@ -85,8 +85,7 @@ void X11Locker::initialize()
 
 void X11Locker::showLockWindow()
 {
-    m_background->hide();
-    m_background->lower();
+    m_background->show();
 
     // Some xscreensaver hacks check for this property
     const char *version = "KDE 4.0";
```

Unfortunately it's not fixed on my system either.
I'm running an up-to-date arch

OS: Arch Linux x86_64
DE: Plasma 6.2.5
WM: KWin
Theme: Breeze-Dark [GTK2], Breeze [GTK3]

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

kscreenlocker-6.2.5 with patch from Comment 101 built for Fedora 41 fixes bug for me
https://koji.fedoraproject.org/koji/taskinfo?taskID=128000736

Can anyone test https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/257 ?

(In reply to Fushan Wen from comment #105)
> Can anyone test
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/257 ?

Unfortunately this patch does not change anything and a black screen appears randomly.

(In reply to nucleo from comment #106)
> (In reply to Fushan Wen from comment #105)
> > Can anyone test
> > https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/257 ?
> 
> Unfortunately this patch does not change anything and a black screen appears
> randomly.

There might be other causes but I need to merge the fix to find out more possible causes.

Git commit 0b208d59e86445f1a102c3e934dbd774d08c0714 by Fushan Wen.
Committed on 30/01/2025 at 09:08.
Pushed by fusionfuture into branch 'master'.

X11Locker: always call stayOnTop when receiving XCB_MAP_NOTIFY to fix black screen

If a window was shown up previously and is hidden for now with the
background window together, m_allowedWindows will contain the window.
When the window shows up again, it will also raise the background
window. But when handling XCB_MAP_NOTIFY event from the background window,
stayOnTop is not called, so the background window becomes the top window.

M  +3    -2    x11locker.cpp

https://invent.kde.org/plasma/kscreenlocker/-/commit/0b208d59e86445f1a102c3e934dbd774d08c0714

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

Git commit 4706bfbce425335dbc4deae23c735ba7d2e040f9 by Fushan Wen.
Committed on 30/01/2025 at 09:13.
Pushed by fusionfuture into branch 'Plasma/6.3'.

X11Locker: always call stayOnTop when receiving XCB_MAP_NOTIFY to fix black screen

If a window was shown up previously and is hidden for now with the
background window together, m_allowedWindows will contain the window.
When the window shows up again, it will also raise the background
window. But when handling XCB_MAP_NOTIFY event from the background window,
stayOnTop is not called, so the background window becomes the top window.


(cherry picked from commit 0b208d59e86445f1a102c3e934dbd774d08c0714)

Co-authored-by: Fushan Wen <qydwhotmail@gmail.com>

M  +3    -2    x11locker.cpp

https://invent.kde.org/plasma/kscreenlocker/-/commit/4706bfbce425335dbc4deae23c735ba7d2e040f9

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

(In reply to nucleo from comment #106)
> (In reply to Fushan Wen from comment #105)
> > Can anyone test
> > https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/257 ?
> 
> Unfortunately this patch does not change anything and a black screen appears
> randomly.

Can you also test https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/260 ?

Black screen still appears randomly after applying patches

https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/259
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/260

I also experience this bug on Arch (Plasma 6.2.5, X11), with a Lenovo IdeaPad with 16 × AMD Ryzen 7 5800H with Radeon Graphics.

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

If I apply only this patch
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/264
then black screen still appears randomly.

What is the current status of this bug?Anyone using pasma 6.3? Is this fixed in 6.3?

I didn't see the problem in 6.3 on X11 with or without multiscreen.

(In reply to Fushan Wen from comment #118)
> I didn't see the problem in 6.3 on X11 with or without multiscreen.

I loved 5.27.11,it was stable enough, but gentoo dropped it since Plasma:6 stable release published, I had to use DWM, waiting for bug get fixed and change it to plasma. I also have problems with sddm on Plasma:6(X11). Scaling on 4K screen is not working anymore, sddm ui elememts are tiny.... Anyway, thank you 老铁

(In reply to Fushan Wen from comment #118)
> I didn't see the problem in 6.3 on X11 with or without multiscreen.
Also no problem for me in Fedora 41 with Plasma 6.3.0 and Qt 6.8.2.

(In reply to nucleo from comment #120)
> (In reply to Fushan Wen from comment #118)
> > I didn't see the problem in 6.3 on X11 with or without multiscreen.
> Also no problem for me in Fedora 41 with Plasma 6.3.0 and Qt 6.8.2.

Please test again when you upgrade Plasma to 6.3.1. If you still can't reproduce then the bug is finally fixed.

Is anyone who was experiencing this in the past unable to reproduce the issue with Plasma 6.3.1 now?

I am on latest Arch, Plasma 6.3.1.1, and still have black screen with cursor after resuming from sleep on x11 session. (does not happen on wayland).

(In reply to Roman from comment #123)
> I am on latest Arch, Plasma 6.3.1.1, and still have black screen with cursor
> after resuming from sleep on x11 session. (does not happen on wayland).

Me too.

The bug doesn't show up for me anymore.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.1
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit)
Graphics Platform: X11

Updated to 6.3.1 and the bug seems to be fixed. There is no flashing of the content "behind" the lock screen.

Operating System: Ubuntu 24.04.2 LTS (Noble Numbat)
KDE Plasma Version: 6.3.1
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.11.0-17-generic (64-bit)
Graphics Platform: X11

For me the bug was gone in 6.3.0 and remains fixed in 6.3.1. This is on Arch Linux.

(In reply to Roman from comment #123)
> I am on latest Arch, Plasma 6.3.1.1, and still have black screen with cursor
> after resuming from sleep on x11 session. (does not happen on wayland).

Roman, do you have fingerprint unlocking set up? If so, your issue is likely Bug 500478.

(In reply to Nate Graham from comment #128)
> (In reply to Roman from comment #123)
> > I am on latest Arch, Plasma 6.3.1.1, and still have black screen with cursor
> > after resuming from sleep on x11 session. (does not happen on wayland).
> 
> Roman, do you have fingerprint unlocking set up? If so, your issue is likely
> Bug 500478.

Nope. Using normal password login.
But as I've mentioned before, I only have this issue after waking from sleep, not after just locking screen.

Adding the x11-only keyword

Prior to 6.3.0, I had a ~15% success rate.  After 6.3.0, and including 6.3.1, I've had a 100% success rate so far.  I'm on a desktop, I lock my screen frequently, but don't ever suspend the machine.

(In reply to Roman from comment #123)
> I am on latest Arch, Plasma 6.3.1.1, and still have black screen with cursor
> after resuming from sleep on x11 session. (does not happen on wayland).

If you run `DISPLAY=:0 xrefresh` from the ssh, will the lock screen show up?

It sounds to me like this is fixed, and people still experiencing issues are hitting slightly different ones — perhaps only after lock plus suspend, for example.

If you're still experiencing any such issues, please open new bug reports for them. Thanks a lot!

Git commit 4ce5756a5308a74daa51fae7c1894a78fb33ace0 by David Edmundson.
Committed on 06/03/2025 at 13:45.
Pushed by davidedmundson into branch 'master'.

x11: Update XStacking order when adding override-redirect windows

Kwin uses it's own stacking order for managed windows and X11's stacking
order directly for unmanaged windows.

The X11 stacking order is updated only in resonse to
XCB_CONFIGURE_NOTIFY on the root window, but if this fires before the
window is mapped by kwin the window is not added to the unmanaged stack.

This can leave things out of sync when we have multiple fullscreen
unmanaged windows, which is the case of the lockscreen.

M  +50   -0    autotests/integration/x11_window_test.cpp
M  +3    -1    src/events.cpp
M  +3    -6    src/layers.cpp
M  +1    -0    src/workspace.cpp
M  +1    -1    src/workspace.h

https://invent.kde.org/plasma/kwin/-/commit/4ce5756a5308a74daa51fae7c1894a78fb33ace0

Git commit f3452076a7e710e1d165ed3d759a2cb17bad1366 by David Edmundson, on behalf of David Edmundson.
Committed on 06/03/2025 at 14:08.
Pushed by davidedmundson into branch 'Plasma/6.3'.

x11: Update XStacking order when adding override-redirect windows

Kwin uses it's own stacking order for managed windows and X11's stacking
order directly for unmanaged windows.

The X11 stacking order is updated only in resonse to
XCB_CONFIGURE_NOTIFY on the root window, but if this fires before the
window is mapped by kwin the window is not added to the unmanaged stack.

This can leave things out of sync when we have multiple fullscreen
unmanaged windows, which is the case of the lockscreen.


(cherry picked from commit 4ce5756a5308a74daa51fae7c1894a78fb33ace0)

Co-authored-by: David Edmundson <kde@davidedmundson.co.uk>

M  +50   -0    autotests/integration/x11_window_test.cpp
M  +3    -1    src/events.cpp
M  +3    -6    src/layers.cpp
M  +1    -0    src/workspace.cpp
M  +1    -1    src/workspace.h

https://invent.kde.org/plasma/kwin/-/commit/f3452076a7e710e1d165ed3d759a2cb17bad1366

Git commit 94b33d380a0cf3e39f3cecd9069c660d10446cac by Vlad Zahorodnii, on behalf of David Edmundson.
Committed on 06/03/2025 at 15:13.
Pushed by vladz into branch 'master'.

x11: Update XStacking order when adding override-redirect windows

Kwin uses it's own stacking order for managed windows and X11's stacking
order directly for unmanaged windows.

The X11 stacking order is updated only in resonse to
XCB_CONFIGURE_NOTIFY on the root window, but if this fires before the
window is mapped by kwin the window is not added to the unmanaged stack.

This can leave things out of sync when we have multiple fullscreen
unmanaged windows, which is the case of the lockscreen.

M  +50   -0    autotests/integration/x11_window_test.cpp
M  +3    -1    src/events.cpp
M  +3    -6    src/layers.cpp
M  +1    -0    src/workspace.cpp
M  +1    -1    src/workspace.h

https://invent.kde.org/plasma/kwin-x11/-/commit/94b33d380a0cf3e39f3cecd9069c660d10446cac