With Plasma 5 our lock screen architecture changed significantly. For example we do no longer support screen saver hacks or widgets on top of the locked screen. Both are very unlikely to make a return in future releases. This means that bug reports against the old infrastructure might no longer apply to our current code base. Two weeks ago I went through all bug reports and feature requests to evaluate whether they still apply to our new infrastructure or should be closed.
This is something I do not like to do. I find it extremely sad to close bug reports because they are outdated. Especially if the bugs have been open for several years without any activity. After going through all those reports it is obvious that we offered too many possibilities to configure the screen locker with too few people caring about it. The number of available screen savers was just immense – especially if one considers that there are also 3rd party savers. While it’s easy to install them, there is basically nobody who cared about them. Some are decades old with the devs having moved on years ago.
Apart from that one could also notice that there were important features missing in our lock screen: audio and multimedia control. The problem is obvious: you suspend your notebook while audio is playing, resume in a place where it should not play audio (e.g. classes) and first need to unlock the screen before being able to mute the audio. An unpleasant experience.
The problem here is that media keys are not supposed to work. The lock screen grabs all keyboard input and prevents other applications to get the keyboard input. This includes our global keyboard infrastructure. We cannot just forward all keys to the global keyboard infrastructure as that could be used to create a key logger when the screen is locked. Even more: most short cuts shouldn’t be invokable when the screen is locked, e.g. you don’t want the desktop to switch.
After brooding over it for a few days I had an idea on how to resolve the problem: the lock screen needs to integrate with our globalshortcut handling. When the screen gets locked we get the available shortcuts from the daemon and map them against a white list of allowed shortcuts. Whenever a key is now pressed while the screen is locked, it’s verified against the fetched list. If we have a match the shortcut is invoked. Not all shortcuts are supported, though. The architecture ensures that one cannot abuse the infrastructure to turn it into a key logger. All alphanumeric keys are excluded. In addition it uses as mentioned a white list, which is not configurable, but hard coded on purpose. At the moment we support only a very limited set of global shortcuts: volume keys, brightness keys and media control keys.
Media control keys were also an interesting topic to work on. Our Plasma session didn’t have any global shortcuts for media handling, so there was nothing which our lock screen could do about it. It cannot figure out whether there is a media application running and then invoke an action on it.
So I stepped back and thought about whether there is a better way to solve it in a general way. Plasma supports the mpris2 interface allowing to control any mpris2-enabled media application. What if the mpris2 engine inside Plasma binds the multi media keys? They could forward to the currently running media player, give us a consistent way to interact with media players and allow us to expose it in the lock screen. So now we have by default mapped the media player controls as global shortcut delegating to any media application. If you press the “Play” button it will Play/Pause VLC, no matter whether it’s the active application or not. And in addition also in the lock screen.
Now there was just one problem to solve: pressing shortcuts and not having visual feedback is not that good. On the desktop we show an on-screen-display whenever the volume changes, but as the screen is locked, we cannot see it. So this architecture also needed enhancement. With a few more changes our lock screen is now able to listen to the requests for on-screen-display information and integrate them:
All just for supporting shortcuts in the lock screen.
I prefer an option that mutes automatically the audio just one moment before locking the screen… and unmute the audio N seconds after the resume (N is set by the user, for example 5 seconds, 30 seconds…. or never :D)
I think it’s very much about choosing a technical path that permits to keep the semantics, i.e. “Pause playback!” or “Mute now!”. Permitting global shortcuts loses this piece of information (media playback keys could be mapped to any other action), while mpris calls inherently keep it, no matter the receiver. That nice optical feedback as implemented now could have become somewhat hacky in the former case because there might not even be a media player, although the action succeeded.
So, to me, your solution really appears superiour (as usual for your work. kwin5 shines, too 😉 ) and there’s often a lot to learn by reading your posts. Thanks for that
his is awesome. It has always bugged me that I cannot suspend my notebook using the keyboard shortcut while on lockscreen. Always have to unlock then suspend. Maybe we can whitelist the suspend shortcut too?
Great thinkin and codin’ man! Your post stimulated a few thoughs
Maybe muting audio output (and pausing media players) would be a good default, same way the screen locker “mutes” the display? Maybe it would also be a good idea to leave streams (or maybe the output device) muted when unlocking the session, in case the user changed location or has gotten company and want to keep his or hers guilty pleasure of Justin Biaber a secret.
Maybe muting the audio and display should be disable-able? A possible use-case would be to leave a video or stream playing, but not leaving an unlocked session open? That ties into DPMS though.
Does the whitelisting requirement have to do with X11?
In my particular case I don’t have a keyboard with actual “multimedia keys”, so I’ve created a Global Shortcut for the “Pause” key which toggles play/pause for my preferred media player. I’d hope that this would work under this scheme. Would it?
Kind of: you will need to map your global shortcut to Plasmashell’s shortcut.
Thanks a lot for thinking both about usability and security!
I do like your solution as a first draft, however, I think there are some problems: First of all, it is not very discoverable what’s actually going on. If someone happens to bind something dangerous do the “mute volume” key (maybe because they don’t usually use audio), they accidentally opened a security hole in their computer – and nothing will warn them about this. So I don’t think that whitelisting the keys is necessarily the right approach – it’s the performed actions that should be whitelisted. I assume there are dbus calls for changing volume and screen brightness? Then the lock screen could listen for the relevant keys itself, and trigger appropriate actions via dbus.
The other point is – what about keyboards that don’t have multimedia keys? They are still common, e.g. I have one in my office. Maybe it would be a good idea for the relevant controls (in particular, audio mute) to also be available as clickable buttons.
That’s the case: it’s not the key which is whitelisted, but the action.
> Both are very unlikely to make a return in future releases.
I don’t know what Screensaver hacks you are talking about but widgets on lock screen have become a standards in some form. Android used to offer full widget support on lockscreen which was replaced with limited widget support in Android 5.0. You are allowed to control running apps like music player. If you receive a notification you can double tap it and it will open in front.
These are all valid cases and should be supported in KDE too because more and more folks are going to laptops like tablets.
Fascinating. Have you looked into how android does it? On my cyanogenmod phone, the volume keys work on the lock screen but do not give any visual feedback. I find it pretty awesome that the KDE lock screen works better.
I really like this. Good job.
Stock Android 5.0 does support full volume control from lockscreen. Android also supports full music control from lockscreen. Apps can also publish notification on lockscreen.They did end up removing widgets from lockscreen.
I hate to play the devil’s advocate, but full support for mpris play/pause seems dangerous from a privacy point of view. If I stoped playback before locking the screen, I certainly don’t want anybody to be able to start it again without unlocking.
Fair enough. I need to think about it. Maybe we need to add some kiosk there to lock down the actions?