SUMMARY *** When switching off all connected monitors (all DisplayPort) on Plasma (Wayland) while the screen is locked, then switching them back on later and unlocking the screen, all screens will go black apart from the mouse cursor and stay black. Sometimes the desktop is actually visible for a split second before it goes black. The only way I found to get a desktop back at all is to switch to a different VT and kill plasma from the command line. I have chosen the severity categorization "major" for this, as it can seriously hamper the use of the system as a whole if you're not expecting this, including data loss. My current workaround for this problem is to leave my monitors on when I walk away from my computer for a while. Needless to say, I don't like wasting energy like that. Another workaround would be, of course, to save everything and log out before walking away, but there are often reason for not wanting or being unable to do that. *** STEPS TO REPRODUCE 1. Lock the screen 2. Switch off all connected monitors. (Depending on your monitor and type of connection, you may need to physically disconnect them from the graphics port. In my case, just switching them off is enough.) 3. (Optional) Walk away and do something else for a while 4. Switch all monitors on again 5. Unlock the session by entering the current user's password on the lock screen OBSERVED RESULT All connected monitors show a black screen. Sometimes they show the actual session for a split second before that happens. The mouse cursor is still visible and can still be moved. EXPECTED RESULT The screens should show the session as it was before the screen was first locked. SOFTWARE/OS VERSIONS Windows: n/a macOS: n/a Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION This is when running on Wayland. I have not tried on X11.
What graphics card are you using? Did your laptop suspend to ram in the mean time? FWIW I can't reproduce on plasma 6, wayland, arch linux, nvidia dgpu+intel igpu. Unplugging and replugging an external monitor during lock works for me.
(In reply to fanzhuyifan from comment #1) > What graphics card are you using? It's and AMD Radeon RX 5700 XT. > Did your laptop suspend to ram in the mean time? This happened on my desktop, not a laptop, and the desktop did not do any suspend operations in that time. Or any other time, because I never configured it to do suspend. My laptop actually did suspend to RAM in that time, but I doubt that is related...
Hello, I often have the same issue. Steps to reproduce: 1. Login on TTY1 and start plasma session. 2. Set "Screen Locking -> Lock screen automatically -> After" to the 1 minute. 3. Enable "Energy Saving -> <your current profile tab, ex. On AC Power> -> Turn off screen" and set "When locked, turn off screen" to the 30 seconds. 4. Switch to another VT or graphic session, for example TTY2 with logged user2. 5. Wait for more than 1m 30s. 6. Switch to the TTY1 -> you'll get only black screen with cursor. OS: Archlinux KDE Plasma: 5.93.0.r67.gdce80ad KDE Framework: 5.249.0.r3.g45d7321 QT6: 6.6.2 GPU device: Mesa Intel(R) UHD Graphics 630 (CFL GT2)
Git commit 9e3e5675924c9b9772693717f4e2b80d0ff394bd by Jakob Petsovits. Committed on 20/02/2024 at 19:29. Pushed by jpetso into branch 'master'. backends/drm: Undo fade-out effect upon unsuccessful DPMS Off DrmOutput::setDrmDpmsMode() already takes care of reverting any pending output pipeline changes, but the aboutToTurnOff signal from setDpmsMode() needs an explicit wakeUp signal to cancel it out. Related: bug 477916 M +4 -1 src/backends/drm/drm_output.cpp https://invent.kde.org/plasma/kwin/-/commit/9e3e5675924c9b9772693717f4e2b80d0ff394bd
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5245
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5246
I believe the patch I merged (see Comment #4, Invent MR https://invent.kde.org/plasma/kwin/-/merge_requests/5240) fixes this issue. It sounds a lot like the same symptoms from Bug 477916 which it was targeting. But I wasn't able to reproduce this issue myself, following the original reproduction steps, likely because I'm on a laptop. The patch is going into Plasma 6.0, please retest with the final release once it's out and report back if the problem was fixed or still persists. Thanks!
Git commit d062ce8750a9fde7973d3457ca5915469925a0e4 by Jakob Petsovits. Committed on 20/02/2024 at 19:43. Pushed by jpetso into branch 'Plasma/6.0'. backends/drm: Undo fade-out effect upon unsuccessful DPMS Off DrmOutput::setDrmDpmsMode() already takes care of reverting any pending output pipeline changes, but the aboutToTurnOff signal from setDpmsMode() needs an explicit wakeUp signal to cancel it out. Related: bug 477916 (cherry picked from commit 9e3e5675924c9b9772693717f4e2b80d0ff394bd) M +4 -1 src/backends/drm/drm_output.cpp https://invent.kde.org/plasma/kwin/-/commit/d062ce8750a9fde7973d3457ca5915469925a0e4
Git commit 26d36b9ac2414adfba344fa16a268976adb7728d by Jakob Petsovits. Committed on 20/02/2024 at 19:45. Pushed by jpetso into branch 'Plasma/5.27'. backends/drm: Undo fade-out effect upon unsuccessful DPMS Off DrmOutput::setDrmDpmsMode() already takes care of reverting any pending output pipeline changes, but the aboutToTurnOff signal from setDpmsMode() needs an explicit wakeUp signal to cancel it out. Related: bug 477916 (cherry picked from commit 9e3e5675924c9b9772693717f4e2b80d0ff394bd) M +4 -1 src/backends/drm/drm_output.cpp https://invent.kde.org/plasma/kwin/-/commit/26d36b9ac2414adfba344fa16a268976adb7728d