Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the top most window. Obviously this does not often work, especially as the whole framework is way older than Compositing.
Too often I have come back to my system or resumed from suspend and seeing my windows shine through. Or seeing some notifications on top of the screen locker. We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor.
The Compositor controls the rendering, so it can ensure that nothing gets above the screen locker. When we have the compositor being responsible for the screen locking we also get nice fading from and back to the desktop for free.
My initial idea was to just move the screen locker to KWin but not changing the unlock dialog. But now I started to play around with QML and need your help:
You can see that I am really no expert in doing user interfaces. So if you have some QML experience or just want to help defining a very important area of Plasma, please get in contact with us. I will do all the JavaScript and coding, so that only the QML is needed.
The new way unfortunately conflicts with the existing screen savers. They are almost 20 years old and we have problems to keep support for them. At the moment we decided that if you have a screen saver configured the old implementation will be used with all the security issues. But we are not yet sure what to do in 4.9. As we use QML it would be possible to write new screensavers in QML. This would allow us to keep the improved security and to only need one code path. But we are unsure how our users will react on removing the X Screen Savers. To find that out we set up a poll on forum.kde.org and I would like to ask you to participate. This will help us to define our next steps.
The new screen locker will also be used by the first version of Plasma Active, which will be released in a few days. There we use the same architecture but ship a different QML file which does the unlocking without needing a password (we only want to protect for unwanted touch events). This shows that it is possible to exchange the QML files for custom screen savers.
Moving the screen locker into KWin has also more security advantages in addition to the protected screen content. Of course KWin is very crash resistant. So if the screen locker crashes KWin will just restart and lock the screen again. Even if KWin would completely fail it is more secure than before as without a window manager you can hardly do anything with the system. Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window. With the locker being a KWin effect it is impossible to trigger this driver crash.
Some users might wonder what that means if they don’t use KWin. Well as the screen locker has been moved to KWin you can no longer lock the screen if not using KWin (the same way you could not lock the screen if not using KRunner before). If you want to lock your screen in Plasma 4.8 but don’t want to use KWin you should get in contact with your Window Manager vendor. Sam from Compiz wanted to add support for it in Compiz. For anything else I don’t know. So why did we do it: we think that the security of most of our users is more important than the need of some users to use a different window manager. Also we had added many integration features to Plasma in the past and if you were not using KWin you lost these features. With the screen locker it is now exactly the same: you lose the integration feature when not using KWin. I also want to remember everybody who wants to complain in the comment section that the KDE Plasma Workspaces are an integrated product consisting of the Plasma Desktop Shell, KWin, KDM, Systemsettings and a few other applications. We develop this as one product, so if you want to remove a part, well that’s your decision, but we have to compromise and we clearly see that other vendors are integrating their window manager even further into the desktop shell than we do.
“Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window.”
Congrats of closing such an annoying bug. By the way, I’m on Kubuntu Oneiric and using the gles version of KWin and it’s working fine.
“As we use QML it would be possible to write new screensavers in QML.”
Can you clearify this one. Does it imply that you have to use QML to write screensavers or will it still be possible to use C/C++?
What for are screensavers anyway nowadays?! IMO kick them!
Two question:
1) Is the screen locker’s wallpaper “sinchronized” with the desktop wallpaper or is It “fixed” just like in KDM?
2) Just curious: what are the security problems with the old screen locker?
1) it will be synchronized with the splash screen
2) the screen is not always blanked.
One think I didn’t understand completely yet is why can’t the old screensavers be wrapped on this new infrastructure.
I am thinking something like an effect: it takes windows, it transforms them, and then outputs them.
Wouldn’t it be possible to get the screensaver window running, but offscreen, and then just composite it behind the lock window or something like that (but without passing input to it)?
I feel like I’m probably missing something (maybe it’s Wayland 🙂
The lock window uses a background image. There is no way to see the screen saver in that case.
Thank you for your answer.
So it would be possible to support old xscreensavers if the lock window was made smaller? (Or if the wallpaper was removed?)
Or would that compromise the security and the other properties desired for the new system?
as soon as we show the old X Screen Saver we get back the security issues we had. And we really don’t want to compromise in such ways. Either the one or the other implementation, but no hacks.
Hm, why not composite the (offscreen rendered) screensaver on top of the unlock dialog. As it is possible to render the screensaver into a small window in the config dialog, it should be possible to render it to somewhere else …
and how do you get to the unlock dialog if there is a window rendered on top of it?
move the mouse (which would exit the screensaver rendering above the lockscreen) ?
adds more complexity which we want to try to avoid.
People using other window managers can surely still lock their screens by just writing a script that calls xscreensaver, no?
if they want to do so, yes
Wouldn’t it be possible in that case to just code in a fallback, which checks for xscreenlock or xscreensaver-command? Not a huge ammount of code, but the few users that are affected by this would be happy again.
Just an idea.
Doesn’t help as the shortcut is bound to KWin.
Martin, a wish. Can you detect if I need a password, or a finger swipe in a fingerprint reader device, to unlock the screen, and provide me with the proper interface? (an input box if it’s a password, an icon telling me to swipe my finger if I need it and I have configured all fprint modules properly).
I’d like to use my fingerprint reader, but I don’t have a proper interface to do this with KDE.
The architecture is there. If the system is configured to use a finger print reader it should just work
Hi! If the new implementation uses KWin API and QML, would new Screenlockers be compatible with other compositing window managers like Mutter oder Compiz if they implement support for it? Or – more specific – can I write a cross-desktop screenlocker without Qt/KDE or GTK+/GNOME dependency? (If not, this wouldn’t necessarily be a bad thing, but it would be interesting to know if this is possible)
If other window managers are interested in it, we can see what is possible. Right now this would be a KWin only solution
Now that would be a great candidate for a standard. Maybe dbus, so whatever application that feels responsible for locking the screen could catch the call. That would also make it possible for external applications to have an unified way to lock the screen if they need to.
Similar how to screensaver- and power management are now at least partially generalized available via dbus.
Just an idea.
Labels, text input fields and buttons in the UI are too “compacted”. Put spaces between them.
As I wrote I am not a user-interface designer and I need help with the QML file to make look it good. If you want to help this would be very appreciated.
I applaud you for going for the consistent solution, and moving away from the hacky one. I never use screensavers anyway, so I wouldn’t even notice it if they weren’t around in 4.8, even.
Having said that, removal of the fallback seems to be something to potentially upset people. Removing features is not something you’d want to do in a point-release, so would it be possible to keep the hack in until 5.0? Only, of course if the depreciated code is maintainable.
The first version based on KDE Frameworks 5 (that’s what I assume you mean with 5.0) will just be an incremental new version just like 4.8 or 4.9. This is clearly not a reason to what with removing features 😉
Just to express my gratitude: thank you. This fixes one of the very few aesthetic problems left in KDE desktop. It would be nice to have way to change the KDM/splash/screenlocker wallpaper without creating new theme though. Hopefully this will be possible when we’ll have QML/Plasma based KDM and KSplash. On single user environments having same wallpaper on log on, splash, desktop and now screen lock gives a nice feel of integrity.
+1
I have an amazing wallpaper (inho) and I would like my desktop to be consistent.
+1
Please focus more on user experience – this is always somehow ignored in KDE – unique splash + wallpaper + lock screen is very nice – on top of that, it should be set in one place by changing wallpaper
Hi,
will the screen locker be still a separate process that can be killed by root to unlock a screen? Sometimes this is of interest if a family’s member asks me to log her session out, but the screen is locked. Or will it be possible to close the screen lock by just entering the root password?
It is not considered but there are ways to unlock the screen as root. I will think about documenting them.
Yes, this would be interesting.
Normally I just change to the tty’s and kill the locker, but if the locker becomes kwin it is not a very good idea.
I would greatly appreciate such documentation, and, if possible, not only for root but also for the user owning the session. The current screenlocker sometimes fails to unlock for me, so I have to go to the console (where, curiously, I can login) and kill it. If the process moves to kwin I’d have no way to get to my system save killing all of X and possibly loosing unsaved work…
Sorry, I’m confused: Can I lock the screen if I don’t have compositing turn on?
yes of course!
I think that’s awesome work. Nicely made stuff!
Okay Guys, fire up Photoshop: It’s time for some mockups!
i think a better poll question is “who uses lock screens?” as a sole home user, i see no use for it. ever. it is one of the first things that gets disabled and the screen saver gets turned on.
maybe you don’t want girlfriend nr1 to read messages of girlfriend nr2 while you are away, leaving your pc running because of some torrents you’re downloading (which you don’t want to be seen by her either) 😉
hmmm…. i do not use screensavers or locking … but i think it is good to have for some users… both of them..
Hi
I’m a big fan of QML and I really want to help you with this screenlocker.
But there are some problems :
* I do not know the API that are used in this screenlocker.
* I do not want to destrop my KDE either, so it is impossible for me to build a KDE trunk.
* I’m quite busy, so I can design some QML mockups but not develop it for full time.
i will try to finish the javascript parts till weekend and could send you my draft qml file. based on that i hope it is easz to define a good looking ui. thanks a lot for the offer to help
Hi!
I love this new idead, it’s about time the screenlocker changes from the all black with that tinsy winsy password form that I get not on my not-able-to-do-composition-with-intel-drivers notebook.
I’d love to help too, I’m not too familiar with QML, but I did spend most of my years working on the ability to make GIMP/Inkscape mockups into reality, so this shouldn’t too hard :).
Where do I sign up?
One of the few things I don’t like in Linux, is that a lot of apps, frameworks, APIs, etc., hang as hard all they can to support old, useless half-broken and deprecated features or hardwares that almost no one use, making their maintaining and evolution harder.
I’m really glad you finally get rid of these old and useless hacks to focus on better, more reliable and safer stuff.
Screensavers are now useless, and even before in the CRT days I rarely used them. Okay there’s some people that still like them, but they will still be able to use them “outside” of KDE. At least now KWin/KDE can step ahead, and no longer be tied to support this garbage.
Some things need to change and evolve, we can’t perpetually hang on broken 20-years old stuff else we’d never get better.
So thumbs up for this decision, and for the new screen locker.
I skimmed the comments on the poll page and I’m a bit confused with the proposal. Is the idea to get rid of the mess that is kscreensaver? In the way that xscreensaver’s author mentions in his FAQ?
If so, then I’m all for that, but if it breaks xscreensaver support in a horrible way that would be one of the main things that would drive me from KDE.
We will get rid off kscreensaver as well as recommend to not use xscreensaver. Of course as long as we are on X you will still be able to just use xscreensaver, but we don’t recommend it. The application is broken as it does not consider the composited case.
Instead of ranting in the man page it would have been better to just talk to the developers and not call them “idiots”. That is really a useful way to communicate with other developers and to advertise your product.
Not to put words in his mouth or defend the guy (cuz he is fairly abrasive at times), I think he tried that before, but couldn’t get through the layers of b.s. that is Gnome.
Regarding talking to developers — in the FAQ he says that he’s willing to accept patches to xscreensaver to make it work with the environment, has KDE tried to contact him?
I mean, just ‘cuz he can be a jerk doesn’t mean he’s not a jerk that’s also right about something. After all, you arrived to the same conclusion about kscreensaver he has (some like, half decade ago), right?
no I came to a completely different conclusion. My conclusion is that xscreensavers is not secure on a completely different layer than what he talks about.
The patches DEs would need are toolkit integration what he considers as insecure, so there is no common sense. XScreensavers is not suited for the use in a desktop environment and he just does not understand it.
Maybe he’s changed his mind on that? You seem to be taking a different approach to the issue than he’s argued about in the past. After all, the X version of xscreensavers is now kind of a secondary activity since OSX has become his primary platform (and that doesn’t use X).
No he hasn’t – see http://www.jwz.org/blog/2011/10/has-gnome-3-decided-that-people-shouldnt-want-screen-savers/ He still fails to see why Xscreensavers does not suit the needs of a Desktop Environment.
Linking to that is kind of a sad irony.
Well, I’m *using* KDE 4 with compositing, and xscreensaver works perfectly. In what way does it ‘fail to meet the needs of a Desktop Environment’? It Just Works, Dammit.
(With a variety of WMs, including fvwm, awesome, and KWin. No, sorry, I’m not going to let you lock me into one window manager, either. Sheesh.)
Let’s see… for example we have popups above the screensaver. Or we have screen not blanked especially with OpenGL screensavers.
Surely the solution here is to add composition awareness to XScreenSaver (which has very nice code), not to gut it all? If you can’t do it out-of-process and must do it in the wm, something smells very bad in your design, IMNSHO.
As for non-blanked screens… if OpenGL screensavers don’t blank the screen, then how does any other full-screen use of OpenGL work? *Most* use of OpenGL is fullscreen, if you include games! Again this suggests a need for a fix either in xscreensaver or in the compositor, to me.
I quite agree. As we cannot fix all the single screen savers we need to fix it in the compositor. Thanks for this suggestion as it is exactly what we want to do.
“it is more secure than before as without a window manager you can hardly do anything with the system”
I disagree. If there’s a terminal open, and there is some text, it’s trivial to start a window manager. Just find the letters (e.g. ‘t’, ‘w’, ‘m’) and middle-click them into terminal, then select the end of the line, and middle click it too, and you’ve got another WM running. In KDE 3.5, when there was no window manager, it was still possible to bring up the Alt+F2 dialog, which made things even easier (I’ll have to check if this is still the case with Plasma)
seriously I know how difficult it is to work without a window manager – it happens to me from time to time that I am there without a window manager. The konsole trick only works if there is a konsole (which normal user has a konsole) and it has also to be top most of stacking order. Additionally the person in question has to know that this is possible and another window manager has to be installed on the system. To me this is a corner case as KWin doesn’t crash to death 🙂
Looks interesting. Got a couple of thoughts/ideas, and was wondering what you think about them:
I recall some planet.kde post about exploring QML based greeters for KDM. Conceptually at least this seems to overlap with the requirements and needs of a lock screen. (There probably ought to be a user-switch function etc.)
… And in any case, there seems to be a lot of overlap in the job of KDM and in the job of Kwin here, especially as the old X based rules for what program does what fade away in the face of Wayland. From here it looks like it might be a good idea to let Kwin either “use” the DM (code) in some way to provide various lock screen features, or conversely for the DM to use Kwin (code) to provide its UI/features…
It is not really the same. The DM allows to select which user to log-in and which session to start as well as how to turn off the system. These are all things not relevant to the lock screen.
The old lockscreen has been developed by the same developers who wrote KDM. So it shares as much as feasible 🙂
I guess so. My point is more that the lock screen appears to be a 50% version of the KDM gui in terms of features. But it would (and arguably should) offer a very consistent (with KDM) UI experience because in both cases their primary function is to log you in to your DE session securely.
(In one case start/restart a session, in another log in to a running session; but that is relatively minor point for the experience thingy.)
As a result, it would seem “the obvious thing” for both to be developed in parallel, and with largely the same code base in terms of handling user-interaction and authentication.
(And systemd integration. It might in future be possible through systemd integration for admins to bring down their users’ KDE sessions cleanly through issuing the relevant systemd commands this way; or in case of mobile devices it might be possible for the system to shut down the DE automatically and resume it with a lockscreen.)
we are planning to get the lock screen being the login screen for single user systems
Could such implentation support home partition encryption or would it be just autologon with screen lock? The latter would be nice on nonencrypted systems as it would make the boot procces smoother, instantly on desktop after password input. But then again password without encryption doesn’t mean much. If that isn’t the idea then would Kwin be started before logon or are we talking about just using the same QML-interface for (Plasma) KDM? Anyhow interesting idea 😀
good point. I had not yet thought about encryption. We will have to stop in KDM in such situations as we need the home dir unlocked before starting the login process.
Just a quick BIG THANKS for this. Just today I unlocked my netbook just to have my desktop fully visible behind the password dialog.
Keep up the good work 😀
Hi Martin,
This is awesome work! Good job!
As for X screensavers and being buggy. I would say: delete them! Move on to the next thing like kwin + QML. Times are changing in the linux GUI landscape and even X itself is getting “close” (as in just a few more years) till Wayland is a real replacement for it. So if you ask me, just don’t worry about the X screensavers. However, what you should do in my opinion here is define some generic way for the screensavers that is not kwin specific so other projects “could” just use the screensaver QML if they want to support QML. Though in reality it’s probably just KDE/kwin using it 😉
Something else completely off topic but gonna ask it anyway.
I’ve seen some very nice QML 3d effects like magic lamp : http://www.youtube.com/watch?v=jFPltyltAWY (lower right animation in that video and the code should be somewhere in the files here : https://qt.gitorious.org/qt-labs/scene-graph-demo) but that made me wonder… Its it somehow possible for KWIN to use QML as the effect system for any effect (specifically window effects like magic lamp)? I’m guessing that will give you some huge benefits like not developing your own opengl code paths for those but rather just use QML for it. Hell, perhaps you can even make the entire compositing part in QML! Just a crazy idea i had ^_^ I hope you could reply on this one.
Regards,
Mark
I have been thinking about using qml for animations and layout but rendering through QML is not possible without rewriting our compositor.
Yeah, figured that would be the case. I’m guessing it’s about time to start thinking about “KWin 2” 😉
Yes security is more important
Yes most of us don’t take care about screensavers (well, it’s nice to have one but it’s not a “must have” in DE so you can get rid of them and maybe supply some new one in the future, asciiquarium is awesome, others looks like crap anyway 😉
So these changes are all in good direction, technically is great BUT KDE needs consistent look across login manager/desktop/lock screen. Desktop wallpaper should stay the same in lockscreen and login manager background (without flickering or changing aspect ratio)
PS if you ask which wallpaper choose to set as background for KDM in multi user login environment the answer is: option is system setting -> login screen:
– “fixed” (one fixed background picked from the list)
– “per user” (default background would be wallpaper of first user on list/default user highlighted, if other user is chosen smooth transition of background should occur, just like in wallpaper slideshow)
I know this is not the place for talking about KDM but as you said it, you provide _Product_ so you need to co-op with each other
Regards, great work!
Hi.
Just wondering, is it possible/easy to have a switch to (de)activate automatic screenlocking when you don’t want it to happen ?
I’m thinking about something like an icon (plasmoid) in the taskbar than you can click to turn it on/off.
Anyways, thank you for working for us users and you do a great work of blogging to keep us all informed. Transparency & communication is always the way to go (and i’m sure people don’t always realize how much time it takes to do so :p)
I think the power management people have been working on something appropriate for 4.8
Thanks Martin! Good job! Go on!!!! 🙂
What about a discrete lock screen similar to the Plasma Active one? There is the background picture (Horos? Customizable? Based on current user’s?), then a clock and at the bottom of the screen the unlock button (or directly the password prompt). Simple and sleek 🙂
You know the Plasma active screenlocker is the first screenlocker based on the new architecture 🙂
And it is f**king awesome! 🙂