Instead of just clipping when HDR content is brighter than the maximum luminance the
screen can show, when HDR metadata indicates this could happen, KWin now
- converts the rgb colors to ICtCp, to split luminance and color
- applies a tone mapping curve that maps the intensity component from
- [0, reference] to [0, newReference] linearly
- [reference, max content luminance] to [newReference, max display luminance] nonlinearly
- converts the resulting ICtCp color back to rgb
The result is that HDR content looks much, much better on SDR displays, at least when decent
HDR metadata is provided.
As wrong metadata could cause this tone mapping to wrongly kick in in games for example, the
environment variable KWIN_DISABLE_TONEMAPPING is provided to disable tone mapping and fall back
to clipping again instead.
Whenever tearing is desired, this does an atomic test to figure out if the current
configuration can do tearing - if not, the backend just transparently falls back to
synchronous commits.
As the kernel (as of Linux 6.9) rejects all commits that are both async and modify
more than the primary plane FB_ID property, this disables the cursor plane and
IN_FENCE_FD usage, to make it more likely for the atomic commit to succeed.
Once these restrictions are loosened, these checks can be removed as well.
This means that we prefer direct scanout over a specific presentation mode (tearing),
which usually just means we first engage direct scanout and program the relevant
properties, and then switch to tearing afterwards.
It also removes a hack for direct scanout with legacy, and is one step less for
implementing overlay plane support.
The NVidia driver maps them to hardware planes, which means they do not
apply to the cursor because the cursor plane doesn't have these color
operations.
BUG: 491634
The check for a shadow buffer used a variable before it was set to the new value,
and the shaders are broken for some reason, so I reverted them to use the previous
code with only the transfer function parameters added.
Rendering intents describe how to handle mapping between different colorspaces,
what to do with out of gamut values and what to do if the whitepoint doesn't match.
This way, clients can choose which behavior their content should get.
Using the custom values for min. and max. luminance in transfer functions, we can reduce the
ranges of values in the shadow buffer to be limited to [0, 1], and with that we can switch
from a floating point buffer back to a normalized format. As gamma 2.2 encoding is much more
efficient at storing color values, this also drops the buffer from 16bpc down to 10bpc.
Furthermore, this offloads the gamma 2.2 -> PQ conversion to KMS when possible, and then uses
the scanout buffer with gamma 2.2 encoding directly. This way the shadow buffer gets completely
skipped and performance and efficiency get improved a lot.
BUG: 491452
CCBUG: 477223
This redefines the transfer functions to have a custom luminance at encoded
value zero, and a custom luminance at encoded value 1, neither of which are
tied to the reference luminance, even for relative transfer functions.
The goal of that is that we can use a gamma 2.2 transfer function for the shadow
buffer, with the reference luminance being much lower than the maximum luminance.
For example, on an HDR screen you might have the reference luminance of 600 nits,
while the maximum luminance is 1000 nits. By representing this in gamma 2.2, we
can use a much smaller amount of bits per color to store the values than if we
used a linear transfer function. An additional benefit is that this way the values
in the buffer can be scaled by arbitrary amounts, for example to limit the range of
values to [0, 1], which can be represented in a normalized buffer
Makes the outputs we are emitting relative to the output position. This
way if there's an esoteric setup or just more than one output, it won't
just always be relative to the first output.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Currently, the code assumes that the primary and the cursor layers are
always present. However, it's not guaranteed if the render backend cannot
be recreated. Specifically:
- the Compositor destroys the EglGbmBackend. The egl gbm backend, in its
turn, resets the primary and the cursor layers to null
- the Compositor tries to create the EglGbmBackend but that fails so it
is destroyed. EglGbmBackend::~EglGbmBackend() calls DrmGpu::releaseBuffers(),
but it hits an unexpected null primary layer.
Normally, the primary and the cursor layers would be created when the
Compositor successfully creates the WorkspaceScene. Since the RenderBackend
fails to initialize, the WorkspaceScene is not created and the DrmGpu
doesn't recreate the layers.
On a lot of hardware, using bigger plane sizes than necessary means wasting power.
This is specifically problematic with the cursor plane, where we so far only had a
single fixed size hint through drm caps, even though the hardware often could use
a smaller cursor size.
This adds support for the per-plane SIZE_HINTS property, which allows us to pick a
smaller cursor size when the cursor image fits into it, and should save some power
that way.
There's generally a lot of problems with higher than 8bpc in docking stations,
especially when multiple monitors are involved. Until these problems are hopefully
eventually fixed on the driver side, limit the bpc to 8 with docks by default
With programmable LUTs, consecutive transfer functions, inverse transfer functions and
multipliers can all be combined into one LUT. This allows offloading operations in more
situations and makes the operations more efficient too, as potentially fewer LUTs have
to be programmed
When the GLX or the EGL backend is destroyed, it is going to reset the
RenderLoop state, including the number of frames in flight. It does so
because of the historical reasons. At the time, there was no output frame
object to track the lifecycle of a frame.
After introducing the OutputFrame and hooking it into the RenderLoop,
the pending frame count will be reset automatically in RenderLoop when
the GLX or the EGL backend is destroyed. But we forgot to remove
the invalidate() function calls. So, when the GLX backend goes down, it
resets the pending frame count to zero and then it destroys the pending
OutputFrame object, which would result in decreasing the pending frame
count by 1 and triggering an assert in the RenderLoopPrivate::notifyFrameDropped()
function.
Since there is the OutputFrame helper now, the invalidate() function
can be dropped. Technically, the invalidate function did more than just
reset pendingFrameCount to 0, for example also stop the compositeTime.
But that should be fairly harmless new behavior.
Some distributions do not wish to build the KWin X11 backend as
they do not use it, even though they wish to maintain X11 support
for Xwayland when using KWin as a Wayland compositor.
Allow this choice by splitting the build flag and setting it up to
forcibly disable building the backend when building X11 code is
switched off.
This allows the user to change the brightness level of content even if there's no
actual underlying "backlight" device. This is the case with many internal OLED
screens for example.
BUG: 413451
This way, KWin can set the brightness on internal panels or external monitors with
DDC/CI support, without being exposed to the mess that is actually directly setting
the brightness.
This also adds a capability flag for brightness control to the output management
protocol. Powerdevil will expose a brightness slider for each output and change the
brightness setting of the output accordingly. KWin in turn changes the brightness
levels of the actual brightness device, or of a multiplier in compositing accordingly.
This matches what we do without color management, and is more what users and app
developers expect. Going with linear blending before was mostly from it being more
"correct" / how physical blending of light works, but that doesn't really matter
when existing software expects it to behave differently.
BUG: 476868
CCBUG: 479755
This makes direct scanout of SDR content on an HDR screen and vice versa possible,
as well as direct scanout while night color is active or the brightness isn't 100%.
This exposes the degamma->ctm->gamma pipeline as a drm color op, which can
be set to a generic color pipeline. The same code can later be adapted to
program the upcoming per-plane color pipeline properties.
This allows encapsulating color operations in a generic way, which can then be used in KMS or shaders.
The class automatically optimizes out unnecessary color operations like identity matrices, and
combines consecutive operations like
- matrix + matrix
- multiplier + multiplier
- matrix + multiplier
- EOTF + inverse EOTF
- relative EOTF + multiplier
to improve efficiency and make KMS offloading easier
This avoids doing multiple atomic tests with outdated state for when multiple
outputs change simultaneously, and avoids crashing because outputs get used
before they're fully constructed
(https://crash-reports.kde.org/organizations/kde/issues/40960)
This ensures that different content on the screen matches with the user configured
reference / SDR luminance, and both simplifies SDR<->HDR mapping by removing the need
for special casing that situation and significantly improves the mapping in some cases.
As we don't get any reference luminance values for HDR content (yet), this commit
assumes that HDR content is prepared for the reference luminance of the preferred
color description.
Brightness is a loose word for how bright we perceive things to be, but the
values we're using are about objective measurements, about luminance instead.
The mastering display colorimetry describes what part of the colorspace
is actually used, which is important when we're sending desired metadata
about a screen using the rec.2020 container colorspace, or when the client
uses an "infinite" / extended colorspace like scRGB
