https://bugs.kde.org/show_bug.cgi?id=485085
--- Comment #16 from Steve Vialle <stev...@runbox.com> --- (In reply to kbtr.buffer098 from comment #13) > the screen locking should happen **before** going to sleep. Of course it should, that's the only way to ensure that, in the (very likely) event GPU memory is restored before the relevant KDE process(es) are thawed, said memory doesn't contain an image of the unlocked desktop. (In reply to kdebugs from comment #15) > The only indication that it has indeed been fixed is to point > to code that was changed. AIUI, the "indication" is a callback from kwaylandserver to say the screenlocker window has been mapped... Not that the framebuffer has actually been updated mind, just that the screenlocker has a window. If that is indeed how it (currently) works, then it's still going to be racy, just less so. On X11 we don't even have that much, as far as I can see it's just "fire and hope". Personally I doubt this will ever be fixed, Nate's comment from the bug I linked (which, IMO, should never have been closed as this was never *properly* addressed) kinda says it all WRT interest: "if you want a better experience here, use Wayland." Why there is so much resistance to implementing even the bare-minimum workaround I don't know. While certainly not ideal, surely a sub-second delay before calling suspend is still preferable to this rather obvious security flaw. -- You are receiving this mail because: You are watching all bug changes.
