When a wl_surface is unmapped, we need to stop updating the buffer
in SurfacePixmapWayland.
However, SurfaceItemWayland::freeze() doesn't unset m_surface, so
the SurfacePixmapWayland keeps updating the buffer even after the
surface is unmapped. This results in some closed windows losing their
contents when playing a window closing animation.
Makes it consistent with other KCMs and and Kirigami KCMs.
**Before:**
{width=431 height=399}{width=430 height=398}{width=431 height=399}
**After:**
{width=433 height=358}{width=436 height=361}
{width=443 height=367}
@teams/vdg
This allows copy pasting text between the overview and regular clients.
QMimeData::data() has a synchronous API. It is a problem for us, the
compositor, because it means we need to block the main thread to read
the mime data. This change adds a one second timeout. If no data arrives
within the next 1 second, the qpa will give up in order to avoid freezing
the screen further. Not sure how this can be handled better without
changing the API of the QMimeData to add async overloads.
BUG: 445751
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.
We only need to override the reference luminance for "absolute" transfer functions, because most
Vulkan apps - games - don't adhere to the standards in this aspect.
For relative transfer functions, the reference luminance should match the maximum luminance of the
transfer function.
ExpoCell is a QQuickItem which manages the geometry of window
thumbnails, movig a bit of the logic in the c++ part.
The partialActivationFactor property switches between the geometry of the window and the
geometry it will have in the overview grid
Get rid of the complicated, 2-stage state machine that the delegate had
Right now it's just a helper to mark items as being affected by some effect,
to prevent direct scanout of the relevant item without needing to block direct
scanout for the whole screen
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.
Previously TrackMouseEffect only listens to mouse events if there are
modifiers configured. So when it was activated by shortcut, the effect
doesn't follow mouse movements.
Instead, listen to mouse events when the effect has been activated, or
if any modifier is configured.
BUG: 487820
This guard was added as part of d335070b80.
The guard as-is does not work correctly. If a client quits at the wrong point
or simply never responds to the request for targets, we get into a stuck state
where we will never update the clipboard from Wayland to X again until the
selection owner changes.
The guard appears to be outdated: The rationale given in the original MR was
that it prevented a race where:
1. The X11 clipboard changes
2. We start fetching targets
3. We notify Wayland clients that the clipboard changed is now empty
4. Klipper replaces the clipboard
5. Kwin then replaces the X11 clipboard
6. X11 finishes fetching targets, but this is now discarded as there's a new
X11 clipboard
However we can not find a path for step 2 to happen in the current codebase.
Potentially due to one of many refactors over the past few years.
The wayland selection is only replaced when targets are fully loaded.
The only way it could happen is if an X11 client replaced the clipboard by
explicitly deleting the old selection first, but this also does not appear to
happen in any tested apps.
BUG: 490577
This also adds support for the linear transfer function, as it can now be used for scRGB,
and it fixes passing on the mastering display primaries and luminance levels.
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
It just tests rec.709 <-> rec.2020 at 0%, 50% and 100% rec.709 luminance, to have
a very simple indicator for when something's gone really wrong while working on
color pipeline changes
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
With this change, KXcursorTheme will be able to load svg cursors provided
by breeze.
If a cursor theme provides both xcursor cursors and svg cursors, the svg
cursors will be preferred.
At the moment, KXcursorTheme doesn't cache svg render results but it could
do that if it becomes a noticeable issue.
Currently, the embedded cursors have effectively a scale factor of 10.
So they look smooth even though the current maxScale is small. With the
svg cursors, the shake cursor needs to provide more reasonable maxScale
values.
Clients can have valid reasons to change the selection when the
same user action that also caused the selection request
to lose keyboard focus. This is notbaly the case for menus
created from a Plasma panel which itself will not take focus
but when clicking on action it only triggers after the menu
is closed.
This also matches what weston and sway do.
BUG:490803
