With XInput2 it's possible that multiple pairs of keyboard and pointers
are connected. As the lock screen only grabbed keyboard and pointer using
the core protocol any additional input devices were still reporting
input events to non-lockscreen windows creating the risk of interaction
with the system and accidentially typing a password where it doesn't
belong.
This change ensures that all additional master devices are also grabbed.
Unfortunately there are no xcb bindings for xinput2 (considered
experimental and thus not build on at least all debian based distros)
and because of that the XLib library is used. This brings some problems
as we cannot process the events (for that we would need xcb bindings,
to get the events). To still be able to get any keyboard and mouse events
we grab using the core protocol as it used to be and then ignore the
"Virtual core" devices and don't grab them with XInput2. Input events
from additional devices are grabbed and ignored, but definately no longer
delivered to other windows.
BUG: 341469
FIXED-IN: 5.3.0
REVIEW: 122558
This change implements support for white listed global shortcuts in
the lock screen. It interacts with KGlobalAccel to fetch shortcuts
and checks them when a key is pressed. For more detailed information
on how this functions, please see the documentation added to the new
file globalacel.h.
So far only shortcuts from kmix are white listed. This allows to
mute and change volume while the screen is locked.
CCBUG: 148228
CCBUG: 104353
FEATURE: 198097
FIXED-IN: 5.3.0
REVIEW: 122419
Start emitting notificiations again. Remove all notification events
which are no longer referenced in the code.
BUG: 276196
FIXED-IN: 5.3.0
REVIEW: 122425
some apps may still use the outdated org.freedesktop.Screensaver
inhibit interface so we still have to query the inhibition state from
PowerDevil
prevents the lock screen from appearing e.g. when playing some video
in Chrome
When the system is going to sleep we want to ensure that the screen gets
locked before the system goes to sleep. Logind provides the inhibitor
locks which can be used for this.
If logind is available ksld gains an inhibitor lock for sleep when the
screen is unlocked. As soon as the screen gets locked the inhibitor lock
is released. In addition it connects to the prepareForSleep signal by
logind and locks the screen.
The solution needs to be extended to have a config option whether the
screen should be locked on sleep. Currently this is provided by
powerdevil. Also the solution can only work properly if power devil uses
logind's sleep dbus interface.
We only want to ensure that the greeter gets started. There is no
need to block for that. Instead we can connect to the error signal
and unlock in case the greeter failed to start.
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
KGlobalAccel takes first shortcut in list as primary and other as
secondary shortcut, and KShortcutsDialog only allows to edit primary
shortcut, see bug https://bugs.kde.org/show_bug.cgi?id=341942
This result in problem where only Screensaver key is configurable and
Alt+Ctrl+L can not be removed. Someone will less likely use Screensaver
key for other purposes.
CCBUG: 336348
Reviewed-by: Marco Martin <notmart@gmail.com>
As we support multiple global shortcuts nowadays we can use both:
* ScreenSaver
* Ctrl+Alt+L
So if the user has a lock screen key it works as expected. If not
the screen can still be locked using the well known shortcut.
REVIEW: 118693
Together with adding back the KCM the settings are slightly adjusted to
have them fit the UI without needing a transformation in the KCM.
* timeout is stored in minutes (used to be seconds)
* grace time is stored in seconds (used to be msec)
* lock is enabled by default
Also disabling the locking after idle timeout is no longer possible. An
endless grace made some sense with the screensavers, but not with the
screenlocker. In order to not break an unknown but maybe valid use case
the option is still available, just not exposed through UI.
REVIEW: 118038
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
The LockWindow deep called into KSLDApp to unlock in case of user
activity during grace time. But LockWindow also emits a signal on user
activity. From an architectural point of view it's better to handle this
directly in the KSLDApp and connect to the signal to unlock if it's in
grace time.
Another advantage is that LockWindow now no longer pulls in the KSLDApp
which improves the unit test situation for the LockWindow as the
lockWindowTest no longer needs to link the complete ksld library.
REVIEW: 118160
The unit test so far only tests establishGrab. This is a little bit
tricky as we need a different X Client which grabs pointer or keyboard
to make establishGrab fail. For that two small helper applications are
included which do nothing else than connecting to X and the one grabbing
keyboard the other grabbing pointer.
The applications are started from the test to get the keyboard/pointer
grabbed which results in ::establishGrab to return false.
What this test is not yet able to test is handling the sleep between two
grab attemps.
As the test is using doUnlock() from KSldApp, the implementation is
changed to use xcb for ungrab pointer/keyboard. With XLib the test would
have needed an XSync which would have required to either add the XLib
call to the test or doUnlock or implement the sync using xcb.
REVIEW: 117995
* we don't have screen savers any more
* it's only used if timeout is larger than 0
Thus the timeout itself is good enough. To make sure the timeout value is
sane it got a min of 0.
Code is only and should only be executed after the timeoutReached signal
from KIdleTime. Using a lambda slot enforces that as well as adding
compile time checking for connect syntax.
Code should only be executed in reply to signal
QProcess::readyReadStandardOutput. From anywhere else it would have been
wrong. By using a lambda slot this gets enforces and the connection gets
compile time checked.
LockProcessFinished should only be invoked when the QProcess::finished
signal fired. Right now it was possible to invoke that from other code
paths. By turning it into a lambda slot this becomes more clear and we
get compile time checking for the connection.
It's only used by ::establishGrab and shouldn't be used from anywhere
else. To make this more clear the code is moved into local static
functions and documented to not be used from anywhere else.
Currently the screen locker just kills the greeter (kscreenlocker_greet)
when the screen is unlocked by the user during the grace time.
But apparently this can leave behind running screensaver processes
launched by the greeter, see the bug report.
This patch changes this to only terminate the greeter, and adds a signal
handler to the greeter to exit gracefully in this case.
The signal handler exits with return code 1, so that it is not possible
to circumvent the password input by just sending a SIGTERM. (the screen
locker restarts the greeter in case it doesn't quit with exit code 0)
CCBUG: 224200
REVIEW: 117644
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
A new class LogindIntegration is added to the screenlocker. This class
listens to the Lock and Unlock signals emitted by the session object on
the logind service.
This is integrated with the screenlocker application to start or quit the
lock when the signals are emitted. This means a locked screen is unlocked
when the Unlock signal is received from logind. Logind is a higher
authority for the screenlocker and thus follows the requests from logind.
BUG: 314989
REVIEW: 117355
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
David Edmundson
Martin Gräßlin
Lukáš Tinkl
Bhushan Shah
Montel Laurent
Aleix Pol
Wolfgang Bauer