Warning messages are not the kind of messages that should be ignored,
they indicate that something is off or wrong.
Also, this makes triaging bugs easier as we no longer have to ask people
to run kwin with the QT_LOGGING_RULES environment variable set.
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.
The compositing timing algorithm assumes that glXSwapBuffers() and
eglSwapBuffers() block. While this was true long time ago with NVIDIA
drivers, nowadays, it's not the case. The NVIDIA driver queues
several buffers in advance and if the application runs out of them,
it will block. With Mesa driver, swapping buffer was never blocking.
This change makes the render backends swap buffers right after ending
a compositing cycle. This may potentially block, but it shouldn't be
an issue with modern drivers. In case it gets proven, we can move
glXSwapBuffers() and eglSwapBuffers() in a separate thread.
Note that this change breaks the compositing timing algorithm, but
it's already sort of broken with Mesa drivers.
Since the Screens class is a convenience wrapper around AbstractOutput
objects that come from the Platform, it should not be platform-specific.
By dropping createScreens(), output-related code becomes simpler.
If eglSwapBuffers() fails, frame scheduling will be broken. KWin can't
recover from that, but still, having a log message might be useful for
the debugging purposes.
At the moment, the gbm_device for the primary device is destroyed before
the EGLDisplay is destroyed. This results in a crash in Mesa.
In order to fix the crash, this change ensures that the EGLDisplay is
destroyed before the gbm device.
Currently, the OpenGLBackend and the QPainterBackend have hooks to
indicate the start and the end of compositing cycle, but in both cases,
the hooks have different names. This change fixes that inconsistency.
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.
At the moment, despite the protocol supporting it, we were not feeding
the EDIDs. KScreen was falling back to the output name so it didn't fail
horribly but it's still a good idea to provide all the data.
Summary:
Notify the driver about the parts of the screen that will be repainted.
In some cases this can be benefitial. This is especially useful on lima
and panfrost devices (e.g. pinephone, pinebook, pinebook pro).
Test Plan:
Tested on a pinebook pro with a late mesa version.
Basically I implemented it, then it didn't work and I fixed it.
Maybe next step we want to look into our damage algorithm.
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.
Currently in order to load an Xcursor theme, kwin uses libwayland api,
which looks really awkward because of the way how the compositor talks
to itself via the internal connection.
The main motivation behind this change is to limit the usage of kwayland
client api in kwin.
Summary:
AbstractOutput::name() behaviour is changed so that it matches the X11
behaviour, showing an identifier like "HDMI-0".
XdgOutput.name is set to this name.
XdgOutput.description is currently set to the manufacturer name and
model, but it's not exposed to Qt so we probably don't care too much.
This should fix plasmashell changing applets when switching between X11
and wayland.
Test Plan:
Relevant unit test
I still need to run it on my laptop.
Reviewers: #kwin, #plasma, zzag
Reviewed By: #kwin, #plasma, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28230
Summary:
As is KWin only had 1 Cursor which was a singleton. This made it impossible for
us to properly implement the tablet (as in drawing tablets) support and show where
we're drawing.
This patch makes it possible to have different Cursors in KWin, it makes all the
current code still follow the mouse but the tablet can still render a cursor.
Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
Reviewers: #kwin, cblack, davidedmundson
Reviewed By: #kwin, cblack, davidedmundson
Subscribers: davidedmundson, cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28155
Summary:
Fixes a crash we would get, we're changing 2 main things:
- release the event queue first, otherwise we'd serve events to
disappearing objects.
- destroy the connection thread object after the thread has quit.
Test Plan: KWin doesn't explode when closing.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28340
Summary: No need to keep them around for no reason.
Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28062
