The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
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.
Plasma Mobile announced that they plan to drop support for Halium
devices, see the announcement blog post [1] for the reasons that led to
such a decision.
But just to summarize, here are some of the key points from the post:
* Some of our team members no longer have access to reference LG Nexus
5X device anymore
* After KDE Neon switched to using Ubuntu 20.04 we no longer are
updating the rootfs for halium devices
* After several important architecture changes in upstream KWin, the
hwcomposer backend might be broken and we have no way of verifying it
If the community members are interested in reviving the hwcomposer
backend,
* it pretty much needs rewrite/re-thinking given differences of hwc1
and hwc2 API for hwcomposer part of it, see also [2]
* It also needs removal of Android 5 based libhardware API as we don't
think code can be kept sane with 3 different levels of ifdefs
* This backend needs better way of fixing difference between
CAF/non-CAF devices then just recompiling with different headers,
maybe env vars?
* This backend does not support various things like transformation/
rotation etc, and is not exactly feature complete as the DRM backend
[1] https://www.plasma-mobile.org/2020/12/14/plasma-mobile-technical-debt.html
[2] 83f563c339
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.
Summary:
Restrict to process with `X-KDE-DBUS-Restricted-Interfaces=org.kde.kwin.Screenshot` in their corresponding Service file,
to take screenshots.
Such a program can now take immediate screenshots.
Adds a utility file to group KService related logic.
Needed for D29408
Reviewers: #kwin, apol, davidedmundson, bport, zzag
Reviewed By: #kwin, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29407
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
Summary: We don't need them in the toplevel directory.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18771
Summary:
There's nothing relevant in kdeglobals and loading it can lead to noise
when deleting groups that override a system default.
We still cascade which will allow kiosk keys to work as well as relevant
system defaults.
Import/Export is unchanged as that already uses SimpleConfig which
includes this flag.
I don't know if it will fix the relevant issue in the bug or just
reduce noise.
CCBUG: 402139
Test Plan: Compiled.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17645
Summary:
Provide the important debug messages which can be used to debug why
virtualkeyboard is not starting.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17454
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
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:
cap_deco was only used in the caption with stripped arg case which was
unused and thus removed. Now cap_deco is completely unused.
Due to that we can also remove the stripped client script which only
manipulated the cap_deco.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7077
Instead of setting our own filter rules we install a categories file
to allow to configure them. This seems to still have them enabled by
default, but should at least give distributions the possibility to
disable logging by default.
Apparently it's not about mplayer but about XV [1], not really a relevant
application nowadays which would be important enough for having hacks.
REVIEW: 117479
[1] https://en.wikipedia.org/wiki/Xv
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
Vlad Zahorodnii
Laurent Montel
Nicolas Fella
Méven Car
Vlad Zahorodnii
David Edmundson
Bhushan Shah
Martin Flöser
l10n daemon script
Laurent Navet
Aleix Pol
Anselmo L. S. Melo
Thomas Lübking