| Summary: | [Wayland] Resuming session after screen lock results in black screen | ||
|---|---|---|---|
| Product: | [Plasma] kscreenlocker | Reporter: | tromzy |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bhush94, bugseforuns, heri+kde, mgraesslin, mlt, sandy.8925 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kscreenlocker/06917c1253eb644e139c28427f4fc4b8f3e0a41b | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
tromzy
2017-03-03 10:01:33 UTC
This happened on my Arch today. Git commit 06917c1253eb644e139c28427f4fc4b8f3e0a41b by Martin Gräßlin. Committed on 16/03/2017 at 18:34. Pushed by graesslin into branch 'master'. [ksld] Don't unset greeter connection on destroy unconditionally Summary: If the greeter exits the Wayland connection gets destroyed and a new greeter with a new Wayland connection gets created. As the destroying of the Wayland connection is async it can happend that the destroy signal is emitted after the new connection is created. So far our code unconditionally reset the connection on destroy which resulted in KWin not being able to recognize the new greeter and only presenting a black screen. After unlock with loginctl unlock-session the session shows a dead greater window. Which can be explained by the connection never getting destroyed. This change verifies that the greeter connection is actually the one which is currently in use. If the greeter dies the new greeter is shown properly in the Wayland session and no dead greeter is shown after unlock. Test Plan: killed kscreenlocker_greet 6 times, always properly restarted Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D5008 M +4 -1 ksldapp.cpp https://commits.kde.org/kscreenlocker/06917c1253eb644e139c28427f4fc4b8f3e0a41b *** Bug 377513 has been marked as a duplicate of this bug. *** Hello, I was wondering if/when this fix will be released in a stable version? I am using 5.9.5, and I am still facing this bug. It will be released in 5.10 *** Bug 379597 has been marked as a duplicate of this bug. *** A workaround is to login to another VT and run `loginctl unlock-session <session ID>` (you'll find the session ID by running `loginctl`). When you switch back to the graphical VT, you'll see the lock screen in a window, which you cannot close. You can, however kill the process using CTRL+ALT+ESC and then clicking the lock-screen-window using the read skull mouse cursor. |