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.
As is, kwin with the drm backend results in the most pleasant user
experience on Wayland. Given that and the fbdev being about to be
dropped, making libdrm a required dependency seems a reasonable decision.
Re-use Qt's implementation of handling non-Latin layouts here
For full ASCII range support (Alt+`, etc.) Qt needs to be patched still,
see QTBUG-90611
BUG: 375518
At the moment, the session code is far from being extensible. If we
decide to add support for libseatd, it will be a challenging task with
the current design of session management code. The goal of this
refactoring is to fix that.
Another motivation behind this change is to prepare session related code
for upstreaming to kwayland-server where it belongs.
-listen <fd> option is deprecated in favor of the -listenfd option. This
change makes kwin query whether Xwayland supports the -listenfd option
at build time. If the pkg-config file is missing, we'll use the old listen
option.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
Plasma-workspace currently starts kwin_wayland before afterwards
continuing to spawn the full session, through whatever mechanism.
We ultimately want to just have systemd manage everything all at once,
but this was not realised in time for 5.21 due to a problem of
propogating environment variables.
By removing this file we go to a working state with the option enabled,
and can build on it for the next release.
BUG: 432189
This logs to a tracefs filesystem which can be viewed in tools such as
gpuvis to see precise timings of activities in relation to other trace
markers in X or graphic drivers.
This patch is loosely based on D23114. Though modified with thread
safety, support for string building, and a RAII pattern for durations.
Ultimately that expanded it somewhat.
Currently, we estimate the expected render time purely based on the
latency policy.
The problem with doing so is that the real render time might be larger,
this can result in frame drops.
In order to avoid frame drops, we need to take into account previous
render times while estimating the next render time. For now, we just
measure how long it takes to record rendering commands on the CPU.
In the future, we might want consider using OpenGL timer queries for
measuring the real render time, but for now, it's good enough.
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.
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
This change introduces a new component - ColorManager that is
responsible for color management stuff.
At the moment, it's very naive. It is useful only for updating gamma
ramps. But in the future, it will be extended with more CMS-related
features.
The ColorManager depends on lcms2 library. This is an optional
dependency. If lcms2 is not installed, the color manager won't be built.
This also fixes the issue where colord and nightcolor overwrite each
other's gamma ramps. With this change, the ColorManager will resolve the
conflict between two.
We need the multimedia component only to play preview videos in a KCM.
The find_package(Qt5Multimedia) is not needed because we already check
if Qt5Multimedia QML module is present using ecm_find_qmlmodule().
The main motivation behind this change is to work around constant build
failures caused by buggy config file of the Qt5::Multimedia component.
Set -DLIBINPUT_HAS_TOTEM per file rather than per target so that all
targets that build it have the define.
This particular file is also used by some tests and this fixes the
warning that this ifdef resolves at once for all targets.
One of the annoying things about EGL headers is that they include
platform headers by default, e.g. on X11, it's Xlib.h, etc.
The problem with Xlib.h is that it uses the define compiler directive to
declare constants and those constants have very generic names, e.g.
'None', which typically conflict with enums, etc.
In order to work around bad things coming from Xlib.h, we include
fixx11.h file that contains some workarounds to redefine some Xlib's
types.
There's a flag or rather two flags (EGL_NO_PLATFORM_SPECIFIC_TYPES and
EGL_NO_X11) that are cross-vendor and they can be used to prevent EGL
headers from including platform specific headers, such as Xlib.h [1]
The benefit of setting those two flags is that you can simply include
EGL/egl.h or epoxy/egl.h and the world won't explode due to Xlib.h
MESA_EGL_NO_X11_HEADERS is set to support older versions of Mesa.
[1] https://github.com/KhronosGroup/EGL-Registry/pull/111
Night Color adjusts the color temperature based on the current time in
your location. It's not a generic color correction module per se.
We need a central component that can be used by both night color and
colord integration to tweak gamma ramps and which will be able to
resolve conflicts between the two. The Night Color manager cannot be
such a thing because of its very specific usecase.
This change converts Night Color into a plugin to prepare some space for
such a component.
The tricky part is that the dbus api of Night Color has "ColorCorrect"
in its name. I'm afraid we cannot do that much about it without breaking
API compatibility.
