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.
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
Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.
While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.
Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.
Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.
Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.
Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.
We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
These signals can be useful if you want to know what output exactly has
been disabled or enabled.
The outputEnabled signal is emitted after the outputAdded signal, and
the outputDisabled signal is emitted before the outputRemoved signal.
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.
This change moves the XRender backend to platformsupport directory,
similar to the OpenGL and the QPainter backend. This allows to put
platform-specific logic in XRenderBackend.
In case hardware transforms can be used again, the shadow framebuffer
must be destroyed; otherwise rendered results will be distorted due to a
mismatch between the dimensions of the shadow framebuffer and the mode
size.
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.
This makes eglSwapBuffers() fail with per screen rendering enabled. In
long term, the screencast plugin has to create its own OpenGL context
and capture window frames after a compositing cycle has been performed.
However, it's currently tricky to do because of monitor screencasting.
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.
As things are right now, we can only do 32bit textures for dmabuf (see
gbm_bo_format in gbm.h). This means that we were lying to our receivers
when we had 24bit textures by then giving a 32bit texture instead.
This changes it so we request a dummy texture before starting and if we
are offered one we assume they're available and offer a 32bits stream
directly (i.e. BGRA).
The buffer offset for client-side decorated windows is not 0, this plus
mixing the frame position and the client size may result in clipped
thumbnails of client-side decorated applications, such as gedit, etc.
BUG: 428595
krunner stuff doesn't really belong in kwin, it has nothing to do with
compositing or any other things that are the domain of compositors.
Given that, being as a plugin suits the krunner integration stuff best.
This change introduces basic colord integration in wayland session. It
is implemented as a binary plugin.
If an output is connected, the plugin will create the corresponding
colord device using the D-Bus API and start monitoring the device for
changes.
When a colord devices changes, the plugin will read the VCGT tag of the
current ICC color profile and apply it.
The scripting api is not suitable for implementing all features that
should not be implemented in libkwin. For example, the krunner
integration or screencasting are the things that don't belong to be
compiled right into kwin and yet we don't have any other choice.
This change introduces a quick and dirty plugin infrastructure that
can be used to implement things such as colord integration, krunner
integration, etc.
Without the KWindowSystem integration plugin, Wayland experience will be
negatively affected because windows created by kwin itself won't behave
as desired. Therefore it makes little sense to load this plugin at runtime.
On wayland, we know we're always going to load our internal QPA. Instead
of shipping a plugin and loading it dynamically we can use Qt static
plugins.
This should result in slightly faster load times, but also reduce the
number of moving pieces for kwin.
This also prevents anyone outside kwin loading our QPA which wouldn't
have made any sense and just crashed.
