Summary:
Compositing today is ubiquitous. There is no reason to keep compositing
specific functions of Toplevel, Client and Workspace classes in the
composite.cpp source file. Instead let these definitions be separated.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D21654
Summary:
KWin is not only an X11 compositing window manager, but also a Wayland
compositor. The Compositor class is used in both cases so in general it
would be nice to keep it as much as possible generic.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19879
Summary:
Deleted has lifetime bounded to effects and scene.
We can't discard Deleted before EffectsHandler is destroyed because
effects that referenced it may call unrefWindow.
On the other hand, the fact that Deleted may outlive scene doesn't
make sense because Deleted exist purely for animation purposes and
nothing more.
This change arranges lifetime of Deleted so it's more reasonable.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18914
Summary:
Currently, each frame callback sent by KWin has the current time in
nanoseconds, but the protocol spec states that we have to send the time
in milliseconds. This is the reason why animations that are driven by
frame callbacks are too fast.
In addition to that, m_timeSinceStart isn't actually "time since start,"
it's rather accumulated duration of all painting cycles. If there is
something to draw and it takes quite a while to compose the scene, maybe
m_timeSinceStart will be close enough to the current time. So, it has
been replaced with QElapsedTimer, this makes the current time correct
and also simplifies code a little bit.
Test Plan: The triangle in weston-subsurfaces no longer spins very fast.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18656
Summary:
On Wayland we cannot switch from OpenGL to QPainter compositor as this
would break any running OpenGL application. KWin registers it's
EGLDisplay to Wayland and without OpenGL this doesn't make sense any
more. We are not able to render OpenGL buffers in the QPainter
compositor.
While it's theoretically possible to switch from QPainter to OpenGL it
doesn't make any sense for the same reason. Any running OpenGL
application would be using llvmpipe and could not be switched to proper
OpenGL.
This change stores the selected compositing type in Platform and the
implementations can use it to restrict the supported compositors. On X11
we don't need this, all other Platforms implement the restriction. Thus
it's no longer possible to switch the backends at runtime.
Test Plan:
Adjusted tests run, no runtime test as gui doesn't support
switching to QPainter anyway.
Reviewers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19084
Summary:
Adds an autotest to show that KWin fails an assertion when a client tries to
resize a sub-surface.
Since it is the first autotest dealing with sub-surfaces explicitly additional
autotest helpers are introduced to allow that.
We also add a new signal in Compositor to spy on to know when the buffer swap
has been completed.
Test Plan:
Test fails as expected:
```
QFATAL : KWin::BufferSizeChangeTest::testShmBufferSizeChangeOnSubSurface() ASSERT: "image.size() == m_size" in file /home/roman/dev/kde/src/kde/workspace/kwin/platformsupport/scenes/opengl/abstract_egl_backend.cpp, line 394
FAIL! : KWin::BufferSizeChangeTest::testShmBufferSizeChangeOnSubSurface() Received a fatal error.
Loc: [Unknown file(0)]
Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 367ms
********* Finished testing of KWin::BufferSizeChangeTest *********
```
Reviewers: #kwin, zzag
Subscribers: zzag, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18452
Summary:
Currently, KWin/Wayland crashes when the compositor is reinitialized.
The reason for that is ShellClient's DecorationRenderer gets destroyed
when the scene is already gone, thus there is no current OpenGL context.
Client works around that issue by destroying scene-specific DecorationRender
in finishCompositing. Such a workaround could be applied to ShellClient
as well, but it would make code more confusing because DecoratedClientImpl
also tries to destroy DecorationRenderer.
A better approach would be to notify DecoratedClientImpl that
compositing is about to be finished, so it can destroy the decoration
renderer when the scene is still alive. This not only fixes the
previously mentioned issue in ShellClient, but also makes code a little
bit tidier.
Test Plan:
Start Plasma on Wayland session, change any compositor settings (e.g.
animation speed).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18921
Summary:
Code that destroys all scene windows when finishing compositing is not
readable. E.g. can you tell what this piece of code is doing without
looking into the source code of Scene::windowClosed?
foreach (Client * c, Workspace::self()->clientList())
m_scene->windowClosed(c, NULL);
This change intoduces removeToplevel(as well its counterpart) method to
the Scene class. The name of the new method much better describes what
we're doing.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18210
Currently, if a Wayland surface registers a frame callback but does
not send a damage event, the callback will not be serviced even after
KWin has completed a compositing cycle and is therefore ready to
render a new frame for the surface. Since some clients, including any
using NVIDIA's Wayland EGL implementation, wait for frame events
before preparing each frame this behavior can result in hangs if a
compositing cycle occurs between registering the frame callback and
sending the damage event.
Instead, in accordance with the Wayland specification, frame callbacks
should be serviced (via KWayland::Server::SurfaceInterface::frameRendered)
for all visible windows - not just those damaged since the last
compositing cycle.
Summary:
The SceneOpenGLES test was starting to randomly crash on my system. On
investigation I observed that there was a graphics reset ("Attempting to
reset compositing.") which triggered a delayed restart of the
compositor. This even was only processed while waiting for XWayland to
terminate. Which resulted in a crash in KWin::getXServerVersion as the
xcb connection broke.
It makes no sense to setup the compositor again during application
shutdown. Thus the dtors set a flag that they are terminating the
application and Compositor::setup is checking for it.
Test Plan: Test no longer crashes, although it goes through the crashing path
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18015
Summary:
Compositing is suspended/finished in a very hard way fashion, effect
windows are destroyed without notifying effects about it.
AnimationEffect tries gracefully release deleted windows, but because
in some cases(like when suspending compositing) a deleted window can
be already destroyed, a segmentation fault can happen.
This change adjusts the order in which effect windows and effects are
destroyed, so AnimationEffect (and other effects) cannot access dangling
pointers.
BUG: 400788
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17311
Summary: We can get rid of the superfluous if/else ladder.
Reviewers: kwin
Subscribers: #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D10393
Summary:
If KWin/Wayland starts up with the QPainter compositor we force software
rendering in QtQuick. It doesn't make sense to try to use the OpenGL
renderer as that normally just results in an abort when trying to create
the QOpenGLContext.
Test Plan:
Run KWin with KWIN_COMPOSE=Q, tried to quick tile a window and
used Alt+Tab. Worked fine, didn't crash anymore.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8663
Summary:
With the new try of all compositor types supported there is an automatic
fallback from OpenGL to XRender/QPainter in case OpenGL setup failed.
So there is no need to invoke a method to do just that.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8364
Summary:
The Compositor now tries to create a Scene not just once but every
type supported by the Platform till it finds one which works. The user's
configuration is only used as a preferred hint and tried first if the
platform supports it.
This brings as an advantage that on platforms such as framebuffer the
user does not need to specify which compositor to use: KWin uses QPainter
automatically.
Also we don't need to do the "translation" from XRender to QPainter any
more. XRender is not supported by any platform using QPainter, so the
user configuration is ignored anyway.
BUG: 350159
FIXED-IN: 5.12.0
Test Plan: Run on framebuffer, verified debug output.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8363
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
Unfortunately a rather large change which required more refactoring than
initially expected. The main problem was that some parts needed to go
into platformsupport so that the platform plugins can link them. Due to
the rather monolithic nature of scene_opengl.h a few changes were
required:
* SceneOpenGL::Texture -> SceneOpenGLTexture
* SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate
* texture based code into dedicated files
* SwapProfiler code into dedicated files
* SwapProfiler only used in x11 variants
* Safety checks for OpenGL scene moved into the new plugin
* signal declared in SceneOpenGL moved to Scene, so that we don't need
to include SceneOpenGL in composite
Test Plan: Nested OpenGL compositor works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7740
Summary:
Several of the subclasses are already derived from QObject.
The main reason is that the class should be moved out of KWin core in
order to move the OpenGL scene into a plugin. As Compositor calls into
the AbstractEglBackend to unbind the wayland display this creates a
problem which is easily solved by turning the AbstractEglBackend into a
QObject and connect to the signal emitted by the Compositor.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7669
Summary:
The compositor needs to claim the X11 compositor selection and redirect
the X11 windows. This of course only makes sense when having X11 support.
This change refactors the code so that if X11 support is missing the code
is not executed, but as soon as X11 support comes available the selection
gets claimed.
Also if the connection goes away the selection is deleted, though it
might be that this does not work as KSelectionOwner might call into xcb
and cause a crash. This needs to be tested once we start supporting
XWayland going away.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7504
This change is similar to D7232 and moves the scene_qpainter into a
dedicated plugin. Compared to the XRender case it's more complicated as
the platform plugins need to implement a platform specific backend.
The base implementation for this part used to be in scene_qpainter. As
the idea is to completly move it away from KWin core it would be point
less to still have the backend definition in KWin core, but it cannot
be in the scene plugin as otherwise all platforms need to link the
plugin.
To solve this a new platformsupport subdirectory is added which contains
the scene platform backend as a static library. For the OpenGL scene such
a static library will also be required.
Test Plan: SceneQPainter test still passes, nested compositor still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7259
Summary:
First step for loading the compositor Scenes through plugins. The general
idea is that we currently needlessly pull in all the Scenes although only
one will be used.
E.g. on X11 we pull in QPainter, although they are not compatible. On
Wayland we pull in XRender although they are not compatible.
Furthermore our current Scene creation strategy is not really fault
tolerant and can create situations where we don't get a compositor. E.g
on fbdev backend the default settings won't work as it does not support
OpenGL.
Long term I want to tackle those conceptional problems together:
we try to load all plugins supported by the current platform till we have
a scene which works. Thus on Wayland we don't end up in a situation where
we don't have a working compositor because the configuration is bad.
To make this possible the switch statement in the Scene needs to go and
needs to be replaced by a for loop iterating over all the available
scenes on the platform. If we go there it makes sense to replace it
directly with a plugin based approach.
So this is a change which tackles the problem by first introducing the
plugin loading. The xrender based scene (as it's the most simple one)
is moved into a plugin. It is first tried to find a scene plugin and only
if there is none the existing code is used.
Test Plan: Tested all scenes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7232
Summary:
The OverlayWindowX11 also inherits from X11EventFilter and performs
the filtering itself.
Test Plan: Compiles, not yet tested as I'm on Wayland
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7197
Introduce a method Workspace::markXStackingOrderAsDirty
Summary:
This method replaces the calls x_stacking_dirty = true in the code base
allowing for further refactoring of that functionality.
Remove roundtrip to XServer from Workspace::xStackingOrder
The method xStackingOrder is only used during a Compositor paint pass.
If the stacking order had changed, the method updated the stacking order
from X by performing a sync XQueryTree. With other words we had a round
trip to the X server directly in the paint pass.
This change rearchitectures this area by making better use of xcb. When
we notice that the stacking order changed and an XQueryTree is needed,
we directly send out the request. When xStackingOrder is finally called,
which normally happens a few milliseconds later, the reply is retreived.
In the worst case it still blocks, but in most cases the roundtrip is
gone.
If the stacking order changed again before accessing xStackingOrder the
running request is cancelled and a new request is issued. So whenever we
get into xStackingOrder it will have the current state.
The updating of the xStackingOrder is moved into a dedicated method and
xStackingOrder invokes it through a const_cast instead of operating on
mutable variables.
Test Plan: Normal system usage, no issues
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6323
Summary:
While investigating a repaint issue I had a hard time to work with the
code and decided to change it to a more modern variant.
Instead of duplicating the same logic for each of the lists it's now
moved into a dedicated templated method which used std::any_of. Which is
exactly the algorithm we need: if there is any window with a non empty
repaints region it should return true.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3397
Summary:
With nouveau driver it can happen that KWin gets frozen when first trying
to render with OpenGL. This results in a freeze of the complete desktop
as the compositor is non functional.
Our OpenGL breakage detection is only able to detect crashes, but not
freezes. This change improves it by also added a freeze protection.
In the PreInit stage a thread is started with a QTimer of 15 sec. If the
timer fires, qFatal is triggered to terminate KWin. This can only happen
if the creation of the OpenGL compositor takes longer than said 15 sec.
In the PostInit stage the timer gets deleted and the thread stopeed
again.
Thus if a freeze is detected the OpenGL unsafe protection is written into
the config. KWin aborts and gets restarted by DrKonqui. The new KWin
instance will no longer try to activate the freezing OpenGL as the
protection is set.
If KWin doesn't freeze the protection is removed from the config as
we are used to.
Check for freezes for the first n frames, not just the first
This patch changes the freeze detection code to detect freezes in the
first 30 frames (by default, users can change that with the
KWIN_MAX_FRAMES_TESTED environment variable). This detects
successfully the freezes associated to nouveau drivers
in https://bugzilla.suse.com/show_bug.cgi?id=1005323
Reviewers: davidedmundson, #plasma, #kwin, graesslin
Reviewed By: #plasma, #kwin, graesslin
Subscribers: luebking, graesslin, kwin, plasma-devel, davidedmundson
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3132
This fixes a regression found in TestSceneQPainter for restarting the
Compositor. The internal clients were never added to the Scene.
We cannot just call setupCompositing because there is a phase during
startup where setupCompositing already passes but the Compositor is not
yet fully initialized. Thus it could happen that it's called twice which
makes the Scene assert.
To solve that setupCompositing and finishCompositing are now overriden
in ShellClient and track whether they successfully called
setupCompositing.
We should be able to restart the Compositor also on Wayland.
As the Compositor might be terminated after Workspace we need to
ensure to not call into Workspace while doing finishCompositing.
Reviewed-By: bshah
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
Summary:
This change ensures that KWin doesn't crash in the QPainter scene if
the compositor gets restarted and if there are Wayland clients.
BUG: 365471
Test Plan:
Test case added to scene qpainter which triggers a restart
of the Compositor with a window being shown. Verifies that rendering
is correct afterwards.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2185
Summary:
KWin needs to support restarting the OpenGL compositor in case of a
graphics reset event.
On Wayland the tricky part is that the applications should not notice
this. Most importantly KWin cannot just destroy the EGLDisplay and create
a new one. But this is how a restart works: the complete compositor gets
torn down and recreated - including the EGLDisplay.
This change moves ownership of the EGLDisplay to the Platform.
The AbstractEglBackend subclasses query the Platform whether there is
already an EGLDisplay. Only if there is no EGLDisplay the EGLDisplay is
created and only if no EGLDisplay is registered with Wayland the bind
is performed.
Another change is regarding the destruction: the AbstractEglDisplay does
no longer unbind the Wayland display and does no longer destroy the
EGLDisplay. The EGLDisplay is destroyed by the Platform - so very late
on application exit. The Wayland display is unbound when the Compositor
terminates.
Test Plan:
Limited testing with the added auto-test. This one needs to
be extended to fully verify that OpenGL applications continue to work.
But this requires build.kde.org to support OpenGL on Wayland.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2202
This is responsible for plasmashell freezing when screen is locked.
The change itself was not wrong, but we first need to enable the
infrastructure to "fake" rendering when screen is locked/disabled, etc.
Summary:
So far when a ShellClient got unmapped ready_for_painting was set to
false. That is the ShellClient was treated in the same way as a not
yet shown window. It was completely excluded from painting, a close
animation impossible.
This change makes use of the functionality available in
Client::hiddenInternal(). The window is considered as hidden, thus
still excluded from e.g. getting input events, but could be rendered
any time as we still have a previous window pixmap (if referenced).
This allows to have it considered in the rendering pass, but effects
still cannot make use of it as that state is not yet exposed to the
effects.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2083
On Wayland tear down the Workspace gets destroyed before the Compositor
gets destroyed. If the timer fires in that area, the Compositor would
crash. It's not possible to start the timer if the Workspace is
destroyed, thus it should also be stoped on Workspace destroy.
Reviewed-By: Bhushan Shah
Summary:
A new virtual method createOpenGLSafePoint is added to Platform.
This is invoked through the Compositor with a PreInit and a PostInit
argument pre and post creating the SceneOpenGL.
The Platform plugin can implement this and use it for detecting whether
creating the OpenGL compositor on this platform crashed in the past.
Thus it's the base for the openGLIsBroken platform check.
The x11 standalone plugin is the first to implement this functionality
using the previous code which was designed for X11.
This also means that a crash of the OpenGL compositor during init on
Wayland won't result in OpenGL being disabled.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1582
Summary:
So far the OpenGL is unsafe check functionality in Compositor disabled
OpenGL compositing if glx is not available and we are in standalone X11
mode.
This is technically no longer correct for quite some time. Just because
GLX is not available doesn't mean that OpenGL doesn't work. We have an
EGL backend. So let's try to use that if glx is not available.
This change removes the check completely from Compositor. Instead the
standalone x11 plugin checks whether glx is available prior to createing
the glx backend. If not available it falls through to the egl backend.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1581
Summary:
CompositingPrefs is only relevant for X11 standalone. It had some
"hacks" to make it not block Compositing on Wayland. Thus it was in
its current form not really useful.
Now all the functionality is provided through Platform with a default
implementation which is sensible for Wayland platforms.
The X11 standalone platform implements the new methods with the
Wayland checks removed.
In addition all calls to CompositingPrefs now go through the platform
directly and CompositingPrefs is completely dropped.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1576
Summary:
This change reduces the windowing system specific code pathes. Instead
of checking whether we are on X11 or Wayland to decide whether
compositing is required, we just ask the Platform.
The default is true, only x11 standalone allows to not require
compositing.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1575
Summary:
This ensures that frameRendered is also sent if we start a Wayland Server
on X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1597
Summary:
Instead of checking the operation mode for X11, we check whether the
damage_handle is created. This fixes a bad damage warning for Wayland
windows in kwin_x11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1490
Summary:
If the Toplevel has a Wayland Surface we don't want an X11 damage
handle. Ideally we would just check for the Surface and get rid of
the operation mode check. But setupCompositing is called for Xwayland
clients before the surface is set.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1486
Summary:
Instead of binding to the OperationMode whether the damage_handle
should be destroyed, we bind it to whether damage_handle got created.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1483
So far if the Scene creation failed kwin_wayland went into a shutdown,
but didn't succeed because the thread to start Xwayland was already
running: it froze.
This change introduces a new signal in Compositor: sceneCreated. The
startup of Xwayland is bound to this signal. If it gets fired KWin can
startup Xwayland. If it does not get fired, KWin terminates correctly.
