For the screenlocker architecture to work it's crucial that the views
are shown as fast as possible with valid content. The OpenGL context
initializes with a copy of the current framebuffer (which is the unlocked
screen) and this is rendered as the first content of the lock screen
and stays visible till QtQuick has rendered a proper scene.
Initial rendering of our scene takes some time (> 500 msec) in which
the unlocked screen stays visible, but the architecture thinks it's
already fully locked and e.g. starts suspending the system. This
can result in the system waking up with the screen looking as unlocked.
This change ensures that at least one frame is rendered properly before
starting to load the real scene in an async way. That's most likely just
the black background which means the screen is properly locked, even if
it is not the proper greeter yet. It's fine for the system to suspend in
this stage as the screen is properly black.
REVIEW: 124948
The background of the whole screen locker architecture is black. During
starting the lockscreen there might be a frame with just the background.
To prevent flickering let's better use black instead of the default
white.
All UI is put into a loader to get the actual lock screen loaded faster.
This gets the creation of two views down to about < 600 msec from before
around 1.8 sec. The initial startup time is extremely important to ensure
the screen is properly locked when going to suspend.
REVIEW: 124933
* Don't set BypassWindowManagerHint on platforms != xcb as that
causes on QtWayland to not create the window
* But set the frameless hint on the window (to not get decos)
* showFullscreen vs. normal show depending on testing state
KSld connects to the DBus signals for the OnScreenDisplay and forwards
them to the greeter application through the private Wayland protocol.
The idea here is to not have the greeter connect to the DBus as in future
it would be preferable if the greeter cannot connect to DBus.
The lookandfeel package might expose an object called "onScreenDisplay".
Whenever an OSD message is recieved by the greeter it looks for such an
object and updates the osd specific properties.
The default breeze lookandfeel package integrates the OsdItem from the
same lookandfeel package.
REVIEW: 122452
The greeter installs a custom QQmlNetworkAccessManagerFactory which
creates QNetworkAccessManagers which do not have access to the
network.
Unfortunately this is not a 100 % secure way to disable network, any
plugin could change the factory again and thus enable network. This
is done for example by KDeclarative, so the greeter now first creates
KDeclarative and then sets the custom factory.
It is a sufficient solution to block all network access for pure
QtQuick without a binary package as we would find in a look'n'feel
package.
Network access needs to be blocked in the greeter as otherwise a
look'n'feel package were able to send the entered password (and other
information to the creator of the look'n'feel package.
REVIEW: 121847
The screenlocker_greet needs to tell the parent ksld process which
windows it created. Ksld sends input events to these windows. So
far this was based on an X property on the window. Unfortunately
ksld didn't validate whether the windows tagged with this property
belong to the screenlocker_greet process it started.
With this change the communication for announcing windows is moved
away from the X11 protocol and instead a custom Wayland protocol is
used.
Ksld starts a KWaylandServer when the greet process gets started. It
creates anonymous unix sockets for the connection and passes one
filedescriptor to the started greeter process.
The check for the X property is removed in ksld and instead only
windows ids passed through the Wayland socket connection are
accepted.
REVIEW: 121429
When the look and feel lockscreen theme failed to load for whatever reason,
it is supposed to fall back to a built-in theme to not lock the user out of the system.
The fallback did not work, however, and made the greeter crash with an invalid package
access, trapping you in an endless kscreenlocker_greet reboot loop.
REVIEW: 121333
Logging out from the locked screen is impossible. Logging out means
interaction with the session due to the session manager. The session
manager asks all applications to quit and applications are allowed to
ask for example saving changes. The session manager stopps the
logout in this case and asks the window manager to focus this window
and the session manager will only continue the logout once the
application resolved the situation. At any time in this process the
user is still able to abort the logout!
Switching to the application which needs interaction is impossible,
though as the screen is still locked. The result is a seemingly
frozen system as the logout cannot continue and there is no indication
what is going on.
Of course the lock screen cannot unlock the session for the logout as
that would circumvent the security. If the lock screen would unlock
one would just have to click the button and abort the logout really
fast to have the system unlocked. So this is clearly not an option.
The result is: we cannot implement this functionality in a working
and secure manner, so it's better to remove it.
REVIEW: 120577
BUG: 339453
FIXED-IN: 5.1.1
This adds a button that allows toggling keyboard layouts from the
lockscreen. It talks and listens to the KDED's keyboard module.
REVIEW: 119794
BUG: 338518
FIXED-IN: 5.0.2
The lock screen will now show a warning when Caps Lock is enabled, like it used to
in KDE 4 screen locker.
The patch also removes the old X-based Caps Lock detection from greeterapp.cpp and
instead uses the Keystate DataEngine.
REVIEW: 119797
It's pretty bad if the lockscreen greeter can't find the lookandfeel's
lock screen, so introduce a qrc file with a default simple lock screen that
we can fallback to.
Instead of having the greeter read the settings of the KSLD, KSLD passes
the required values to the greeter as command line arguments. This
ensures that the greeter doesn't show a lock UI while the KSLD is still
in grace time and vice versa.
Two command line options are added:
--graceTime <milliseconds>
--nolock
The option --graceTime starts the timer to show the lock ui on timeout.
The option --nolock is for the case that the KSLD never locks the
screen.
REVIEW: 118214
It was used to ensure that the view which last got pressed on gets
keyboard events. This is no longer needed, after clicking a screen the
keyboard events end on the correct screen.
REVIEW: 118013
case of immediateLock
If the screen locker is set to not require a password to unlock, it will
not show the password input field even when the powermanagement settings
suspend the system and are set to require a password after resume (when
it was already running at that point).
This locks people out of their system.
This patch adds a signal handler for SIGUSR1 that switches the running
greeter to immediateLock mode. The locker sends that signal to make sure
the greeter shows the password input field when necessary.
CCBUG: 327947
CCBUG: 329076
REVIEW: 117091
* Use QCommandLineParser instead of KCmdLineArgs
* Inherit QApplication instead of KApplication
* Use QCoreApplication::setApplicationName and friends
* Drop k4aboutdata
A new Authenticator item is introduced and exported to QML. It provides
a slot tryAuthenticate taking the password as a string. If invoked it
creates a KCheckPass object which handles the communication with the
kcheckpass binary to verify the password. If the authentication succeeded
the Authenticator emits a succeeded() signal, on failure a failed()
signal.
The authentication process is bound to a grace timer. While this timer is
active it's not possible to authenticate again. This state is exposed
with a Q_PROPERTY and used by the UI to disable the password field and
unlock button.
REVIEW: 117321
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0