At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
In order to unlock per screen rendering, we need to track repaints for
every screen individually. While we could do this in the Compositor class,
tracking repaints in the Scene seems a better alternative in long run
because we will have to instantiate a Scene for each composited screen
one day.
In rare cases, the Compositor has to perform a compositing if there is
nothing to repaint. For example, if a client has committed a frame
callback to get notified about the next vblank event without damaging
the surface.
In order to allow per screen rendering, we need the Compositor to be
able to drive rendering on each screen. Currently, it's not possible
because Scene::paint() paints all screen.
With this change, the Compositor will be able to ask the Scene to paint
only a screen with the specific id.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
If the Xwayland process crashes, it will bring down the entire session
together with itself. Obviously, we don't want that. At least, Wayland
clients should survive the crash.
This change refactors relevant X11 parts to handle Xwayland crashes in a
less fatal way.
In order to handle Xwayland crashes better, a pair of start() and stop()
methods had been introduced in the Xwayland class to allow starting and
stopping the Xwayland process at any moment.
If we detect that the Xwayland process has crashed, we will immediately
stop the Xwayland server, which in its turn will deactivate the socket
notifier and destroy all connected X11 clients. Unfortunately, a couple
of subtle changes in X11Client::releaseWindow() and Unmanaged::release()
had to be made to ensure that we are left with a valid state after the
Xwayland server has been stopped.
Summary:
The GLX backend might need a combination of swap and composite timer events for
continous painting.
The reason for that is that if the buffer age extension is not available we
fall back to copies in case not the whole screen is repainted.
The timer logic is adapted to make this possible in a lean way what cleans up
the Compositor class in several ways.
Test Plan: Tested on X11 (with/without swap events, buffer age enabled) and Wayland.
Reviewers: #kwin
Subscribers: hurikhan77, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26216
Summary:
Compositing in X11 was done time shifted, meaning that we paint first, then
wait one vblank interval length and present on prepareRenderingFrame the
previous paint result. This is supposed to make sure we don't miss the vblank
and in case of block till retrace be able to continue issuing commands and
only shortly before next vblank present.
This is counter-intuitiv, not how we do it on Wayland or even on MESA with X.
The reason seems to be that the GLX backend was in the beginning written
against Nvidia proprietary driver which needed this but nowadays even this
driver defaults to non-blocking behavior on buffer swap.
Therefore remove this legacy anomaly fully and directly present after paint.
We then wait one refresh cycle and in the future can optimize this by delaying
the paint and present till shortly before vsync.
Test Plan: kwin_x11 tested on i915 and Nvidia proprietary driver.
Reviewers: #kwin
Subscribers: zzag, alexeymin, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23514
Summary:
Qt's metaobject is rather sensitive with scope resolution.
Foo::Bar and Bar don't always match to a Qt metaobject, even if they
refer to the same thing to a compiler. Here we register
X11Compositor::SuspendReason but Q_ARG uses SuspendReason and they don't
match. This leads to a runtime failure where the method isn't invoked.
Rather than fixing metaobject usage, port the whole thing to lambdas
which does better compile time checking and is generally nicer to read.
BUG: 412353
Test Plan:
Ran xprop to block compositing. Compositing was blocked.
Grepped source code for Q_ARG use
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24244
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
Compositor::hasScene() is redundant. Depending on use case, it can be
replaced by checking either m_state or Compositor::scene().
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23744
Summary:
Neither WaylandCompositor nor X11Compositor have at least one smart
pointer field that points to an incomplete class type, so the destructors
are kind of useless.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23747
Summary: Overlay windows is an X11 thing.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23608
Summary:
Any call made to a virtual method in constructor/destructor of a base
class won't go to a derived class because the base class may access
uninitialized or destroyed resources.
For example, let's consider the following two classes
class Base {
public:
Base() { foo()->bar(); }
virtual ~Base() { foo()->bar(); }
virtual Foo* foo() const { return nullptr; }
};
class Derived : public Base {
public:
Derived() : mFoo(new Foo) {}
~Derived() override { delete mFoo; }
Foo* foo() const override { return mFoo; }
private:
Foo* mFoo;
};
When an instance of Derived class is created, constructors will run in
the following order:
Base()
Derived()
It's not safe to dispatch foo() method call to Derived class because
constructor of Derived hasn't initialized yet mFoo.
Same story with destructors, they'll run in the following order:
~Derived()
~Base()
It's not safe to dispatch foo() method call in the destructor of Base
class to Derived class because mFoo was deleted.
So, what does that weird C++ behavior has something to do with KWin? Well,
recently Compositor class was split into two classes - WaylandCompositor,
and X11Compositor. Some functionality from X11 doesn't make sense on
Wayland. Therefore methods that implement that stuff were "purified," i.e.
they became pure virtual methods. Unfortunately, when Compositor tears
down it may call pure virtual methods on itself. Given that those calls
cannot be dispatched to X11Compositor or WaylandCompositor, the only
choice that C++ runtime has is to throw an exception.
The fix for this very delicate problem is very simple - do not call virtual
methods from constructors and the destructor. Avoid doing that if you can!
This change moves Compositor::updateClientCompositeBlocking to X11Compositor
so it longer has to be a virtual method. Also, it kind of doesn't make sense
to keep it in base Compositor class because compositing can be blocked only
on X11.
BUG: 411049
Test Plan: KWin no longer crashes when running kwin_x11 --replace command.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: anthonyfieroni, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23098
Summary:
This patch is a first take at splitting up of the Compositor class into
Wayland and X11 child classes.
In this first patch we mostly deal with setup and teardown procedures.
A future goal is to further differentiate the compositing part itself too.
Test Plan: Manually X from VT and Wayland nested. Autotests pass.
Reviewers: #kwin
Subscribers: sbergeron, anthonyfieroni, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22195
Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
Replace the several internal state booleans of Compositor with a single
enum to register the current state of the compositor. We register four
states of starting, started, stopping and stopped.
The goal is to replace the several different conditionals when starting
and stopping the compositor with a single well defined flow.
There are currently still some ugly conditionals and some replaced ones
might need some more work.
Test Plan: Manually in X and Wayland. Relevant auto tests pass.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22277
Summary:
Cleans up the Compositor code some more. The check is only
used in a single assert statement.
Test Plan: Compiles.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22278
Summary:
To streamline Compositor code more remove the composite reset timer. The two
times it was used we can either use a singleshot timer instead or connect the
call to a different signal in the X11 backend.
Long term goal is to have a well structured init of the Compositor such that
we can call directly instead.
Test Plan: Manually in X and Wayland nested session.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22270
Summary:
This removes the restart function of the Compositor class and renames the
internal reinitialize function.
Instead of the restart function reinitialize can be called. Reading again
the settings in this case is fine, since it is done rarely. This reduces
the code complexity.
Test Plan: Manually on Wayland and X. 100% autotests pass.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22225
Summary:
As a preparation for further changes clean up the Compositor
class. First step is to use the new slot syntax and rename
some of the slots.
Includes some other minor code style improvements to the class
as well.
Test Plan: Manually in X and Wayland nested session.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D22218
Summary:
Declare it in the source file for internal usage of ApplicationX11 and
Compositor classes. Additionally use modern style connect and do other
code style updates.
Test Plan: Manually in X session and Wayland windowed.
Reviewers: #kwin, zzag
Subscribers: davidedmundson, sbergeron, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D21655
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:
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:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
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 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
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
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
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
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.
Each of the backends becomes a plugin. This allows kwin_wayland to load
the requested plugin and kwin itself doesn't need to link all the
libraries needed. E.g. libdrm is no longer linked if running kwin_x11.
Also this allows to create backends for the non-standard EGL platforms
(examples could be raspberrypi or Android devices).
For Xwayland we need to have the Scene (and EglDisplay) created prior
to starting Xwayland and having X11. This requires creating the
Compositor before creating Workspace and starting Xwayland.
To support this the startup of Compositor is split into two parts:
prior and after Workspace creation.
The change might also be interesting for the kwin_x11 case as it could
result in the compositor being up in a quicker way.
The Compositor is destroyed before the Client and Decorations are
destroyed on shutdown. This meant the Decorations reacted needlessly
on the alpha channel supported. E.g. Aurorae recreated the Decoration
and most likely crashed in Qt.
With this change the signal gets disconnected and the Decorations
just don't do anything.
Move the buffer-swap-pending state from the compositing backends to
the Compositor class. The Compositor is the only class that needs to
access the state, and this way it to do it without calling through
a chain of virtual functions. This commit adds two new functions to
Compositor; aboutToSwapBuffers() and bufferSwapComplete(). The
backends call these functions to set and reset the buffer-swap-pending
state.
This commit also renames a number of functions and variables to make
their meaning clear.
The act of promoting the contents of the back buffer to become the
contents of the front buffer is referred to as posting the buffer,
presenting the buffer, or swapping the buffers; rendering the buffer
is what paintScreen() does.
Similar to the already existing DBusInterface wrapper for the
org.kde.KWin interface a new CompositorDBusInterface is introduced for
org.kde.kwin.Compositing.
That way the DBus interface is split from the implementation and DBus
specific methods are no longer required in the Compositor class.
The deprecated DBus methods
* toggleCompositing(bool)
* setCompositing(bool)
are removed.
REVIEW: 118463
The egl wayland backend registers for the callback for a rendered frame.
This allows to throttle KWin's compositor so that we don't render frames
which wouldn't end up on the screen.
For this the Scene provides a method to query whether the last frame got
rendered. By default this returns true in all backends. The Egl Wayland
backend returns true or false depending on whether the callback for the
last frame was recieved.
In case the last frame has not been renderd when performCompositing is
tried to be called, the method returns just like in the case when the
overlay window is not visible. Once the frame callback has been recieved
performCompositing is invoked again.
