sRGB content is made to be encoded with the sRGB piece-wise transfer function,
and to be decoded by displays with the gamma 2.2 transfer function.
When KWin has a display in sRGB mode, this doesn't make a difference - it
decodes with sRGB and encodes with sRGB, so there's effectively no transformation.
When the display is in PQ mode though, KWin uses the sRGB inverse EOTF for
decoding sRGB content, but not the sRGB EOTF for encoding it again.
To fix this, this commit changes KWin to use the gamma 2.2 EOTF and inverse
EOTF for untagged content. That's not technically correct for sRGB screenshots,
where we'd have to use the piecewise sRGB EOTF, but that's a problem that
can be solved in the future.
The brightness overrides are for displays with missing or broken brightness
data in their EDID, and allow the user to work around those displays. In
the future we could also offer an HDR calibration process that allows determining
the correct brightness values for the screen.
The gamut wideness setting allows the user to tweak what gamut KWin assumes
sRGB applications to have. This is useful for working around the gamut mapping
displays do, which make sRGB content look washed out, and also to allow
users to make colors of sRGB apps look more saturated if they wish to.
As KWin measures render times properly now, these settings and estimations
should no longer be necessary, so this commit replaces them with one hardcoded
algorithm that should prevent most dropped frames and reduce latency
The DisplayPort multi stream path should be more stable in comparison to
connector names, so prefer that for differentiating between outputs with
the same EDID.
BUG: 470718
If a repaint is scheduled in the prePaintScreen() function, we want
it to be applied in the next frame, not the current one.
Currently, it doesn't work like this because prePaintScreen() runs first
then the Compositor gathers repaints and resets them.
This is important to qtquick effects that use qtquick3d as some items in
qtquick3d schedule repaints for the next frame after synchronizing, i.e.
in OffscreenQuickView::update() which is called in prePaintScreen() by
QuickSceneEffect.
Instead of an external service (like KScreen) storing and restoring output configurations,
with this commit KWin takes over that responsibility. This allows it to, among other things,
generate appropriate configs for new sets of outputs immediately, and take KWin-internal information
about outputs into account when generating them.
CCBUG: 474021
CCBUG: 469653
CCBUG: 466342
CCBUG: 470863
CCBUG: 466556
BUG: 466208
BUG: 455082
BUG: 457430
This is useful for the few cases where wheel events are not for
scrolling. For example adjusting the volume in the tray.
In this case having the metadata that the delta is backwards is
important. From a kwin POV it's just proxying the libinput
isNaturalScroll setting to clients.
Tested against "qtbase/examples/widgets/widgets/mousebuttons" with
modified Qt and changing the setting in the UI.
Not mergable until upstream lands.
Relevant link:
https://gitlab.freedesktop.org/whot/wayland/-/merge_requests/1 /
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/183
CCBUG: 442789
Transactions provide a way to apply new surface state to multiple
surfaces atomically.
A transaction can be locked. In which case, it's not going to be applied
until all locks are dropped. For example, this can be used to delay
applying new surface state until the committed buffers become idle.
Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
It never belonged in the OutputBackend, but we also didn't have a better
place when the relevant code had been added.
With the introduction of graphics buffer allocators, it's no longer the
case.
The buffer transform specifies a transform from the buffer coordinate
space to the surface coordinate space.
The inverse buffer transform specifies a transform from the surface
coordinate space to the buffer coordinate space.
OutputTransform::map(QRect, QSizeF) expects both arguments to be in the
same coordinate space.
In case of SurfaceInterfacePrivate::computeSourceBox(), both should be
scaled surface coordinates so bufferTransform.inverted() maps the source
rect to the proper buffer coordinate space.
Instead of hardcoding ARGB8888 and using implicit modifiers, look through
the list of available formats and modifiers and pick a match that egl will
actually accept.
In some cases, it's desired to know what the inverse transform of a
given output transform is. It's possible to make it work by providing
helper functions, but we tend to avoid doing so.
This change converts the OutputTransform from an enum to a class so it's
possible to have both data + methods in the same type. Unfortunately,
unlike Rust, C++ provides no way to attach methods to enums, classes and
structs is the only way to go.
Being in the KWin namespace has a couple of advantages: the enum can be
forward declared, and the transform can be replaced with a slightly more
complex but useful type.
If the surface item's contents is scaled, i.e. its scale factor doesn't
match the output's scale, GL_LINEAR will be applied to smooth the
contents. The unfortunate thing is that it's possible some of the
changed pixels will bleed to the neighbor ones.
In order to handle that scenario better, this change makes the
SurfaceItem expand the damage if there's scale factor mismatch.
bufferSourceBox and bufferTransform properties were introduced to detect
if the surface contents is going to be scaled. bufferSourceBox covers
both crop transform from wp_viewport and scale factor from wl_surface.
bufferTransform is same as wl_surface's buffer transform property.
The bufferSourceBox provides a way to get the source region of the
attached buffer. It can be used to compute the effective scale factor
when using wp_viewport.
