Bug 312669

Is "fast switching" sth. special or just VT7 -> VT8?

Does this depend on compositing being used and is "suspend compositing for fullscreen windows" checked for any account in "kcmshell4 kwincompositing", 3rd tab?
Does unchecking it have any impact?

pot. bug #183496

It is not anything special. Just using the KDE Application Launcher "Leave" -> "Switch user" (which pops up krunner with active accounts and the option to start a new session). (Sorry, "VT7 -> VT8" doesn't mean anything to me.)

I have compositing enabled (OpenGL, Native Qt) and "suspend compositing for fullscreen" UNchecked for all accounts.

I thought the screen locker was moved to the compositor in KDE 4.8 to avoid just this sort of thing?

no. screenlocker is reimplemented and resettled in 4.10
not tested myself yet, though.

i gues what appens here is just that the output gets redirected when you switch to the other x11 display and that causes the flicker.
would need to verify the assumption.

I updated to 4.10 RC2 to see whether it makes any difference, and unfortunately not, even though the lock screen implementation has changed (it's adopted my plasma theme). Whatever is happening during user switching, it is calling the lock screen a little too late.

Do you also see it with compositing disabled?

It happens also when compositing is disabled on both accounts. It can be (but is not always) harder to detect though, since without compositing things move faster, including the flash of the user's screen.

Either the frambuffer exposes this or there's an issue with the locker.

Switching between uncomposited terminals doesn't expose this on even the old locker here. (try navigating directly between the with ctrl+alt+f7 / f8)

I tried navigating directly using ctrl+alt+f7/8 and the same thing happens. (Strangely, switching that way does not always call the screen locker (i.e. ask for a password).)

Is it possible that if you are running a relatively fast machine with ample RAM, the bug isn't noticeable even if present? My machine is an Intel Core Solo ULV 1.06GHz with Intel 945GM graphics and 1GB RAM. When I do a lot of consecutive switching back-and-forth with no applications open, I can't really see the bug.

I can confirm it on KDE 4.9.97.
It can happens also without doing a user switch, simply waking up my laptop from standby. Today I've seen my desktop for about 5~10 seconds before the screen locker appeared.
Maybe it's something related with graphic drivers, but I think that the screen locker should be launched silently when the screen goes black, in order to try to avoid this problem and make the whole screen locking system safer: is it possible to do it?
I'm using a Intel Core Duo ULV with Intel X4500HDM gpu with Fedora 18.

the issue is similar to one reported earlier: https://bugs.kde.org/show_bug.cgi?id=206339

I see the same problem on my netbook with KDE 4.10.1 on Fedora 18: screen locker is started _after_ resume, not _before_ suspend as I expect.

This is a race:
void
KDisplayManager::lockSwitchVT(int vt)
{
    // Lock first, otherwise the lock won't be able to kick in until the session is re-activated.
    QDBusInterface screensaver("org.freedesktop.ScreenSaver", "/ScreenSaver", "org.freedesktop.ScreenSaver");
    screensaver.call("Lock");

    switchVT(vt);
}


Directly after the DBus call is fired the VT switching is performed. The lock screen is not that fast, though, resulting on switching back the screen content being exposed before the screen is locked.

Unfortunately logind doesn't provide an inhibition on VT switching. It might be possible to wait with VT switching till the lock screen reports back that it's locked.

*** Bug 346198 has been marked as a duplicate of this bug. ***

I just followed your steps in Plasma 5.22.5, but fast user switching brings me back to SDDM and requires me to enter a password and does not show the desktop of the other user. It does show a black screen for a very short time when switching from the current desktop to the sddm user switch screen. Is this still an issue for you on Plasma 5.22.5 or newer? If so, can you please provide updated steps to reproduce?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!