We seem to have a problem in the autotest concerning grabbing so
try to make the whole thing less timing dependent.
The XSync should be before the server grab, otherwise it just doesn't
make sense. And all XLib code should do a flush as otherwise we don't
know if that will happen at all.
This unittest verifies that the emergency window is shown by verifying
- There is at least one white and one black pixel
- There is no other colored pixel then black and white
Reviewed-By: Martin Gräßlin
This commit introduces AbstractLocker class, which can be subclassed to
provide platform specific implementation of LockScreen, for example
X11Locker and WaylandLocker.
REVIEW: 125802
Earlier we were showing dummy window to make sure that if background of
X is black and we fail to show our lockwindow, tests wouldn't assume
that lockwindow is shown.
However this solution had flow that window we were showing was not
colored at all. So either it was black or transperant and tests would
pass even if something is broken. This commit fixes it with :
- Show dummy window with red color
- Verify that red colored window is shown
- Show our lock window
- Verify that screen is black
REVIEW: 125805
We handle screen add/remove, but not the active screen we're on changing
size/position.
KScreen can potentially resize an existing screen after it detects one
has been removed, also virtualbox can resize guest displays when the
host resizes the window.
REVIEW: 125605
By grabbing the XServer we can ensure that no other client is
sending X events. This eliminates a possible timing attack in
the time frame between grabbing keyboard and pointer.
At the same time the waiting and try again becomes useless as the
XServer is grabbed and no other client could release the hold
input device grab.
REVIEW: 122528
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
We don't need it as we get keyboard and pointer events anyway (grab),
exposure is set by Qt anyway and for everything else we have
substructure redirect on the root window.
Setting the background pixel is also no longer needed: we render a
black, non-translucent window.
So far the grace time started with the idle timeout. Given that our
greeter takes a few seconds to start it rendered a short grace time
useless as it was quite likely that the grace time already ended when
the first visible feedback was shown to the user.
Now the grace time starts when the greeter is actually shown.
REVIEW: 124917
If the greeter crashes on startup ksld is caught in a restart loop which
causes 100 % CPU usage and makes it impossible to unlock the session.
With this change the greeter is only allowed to crash four times and
ksld goes into an emergency mode. This mode ensures that our black
background window gets shown with a message indicating how to unlock
using loginctl. This is rather technical but better than leaving the
system in a state which makes it impossible to unlock.
Directly unlocking in the error case is not an option as that could
be used to attack the screen locker infrastructure.
BUG: 351696
REVIEW: 124915
The screen is only truly locked once our black background window is
shown. So far we locked once the greeter process was started. At this
point the screen was still unlocked and a suspend would result in system
waking up with an unlocked screen for a brief period.
This change emits the locked signal once we got a MapNotify event for
our black background window which means the screen is properly turned
black and we can allow e.g. going to suspend.
CCBUG: 348850
REVIEW: 124912
LockWindow is mostly just the logic to ensure that the greeter is kept
on top of the stack. In addition it did render a black qwidget. Testing
showed that the paintEvent never got invoked, though, so the rendering
did not really work.
The rendering feature is now split out into a dedicated QRasterWindow
as we don't need a full QWidget for it. It also needed to be split into
a dedicated class as it's not possible to inherit from QSurface and mix
with XLib code (QSurface defines a Window type which bites with XLib).
ConsoleKit2 has the same API as systemd-logind for Lock, Unlock,
PrepareForSleep, and Inhibit. This patch adds the functionality
for ConsoleKit2 while attempting to minimize code duplication.
REVIEW: 124469
* 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
Martin Gräßlin
Bhushan Shah
David Edmundson
l10n daemon script
Eric Koegel
Felix Geyer
Burkhard Lück
Lukáš Tinkl