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
It just shows "Compositing" in the corner and doesn't block direct scanout.
When direct scanout is active, the "Compositing" text isn't visible anymore.
This is useful for debugging performance or power draw issues.
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>
If the application uses a surface with a single-pixel black buffer as a background,
for example behind a video or video game, that surface can be ignored, as the KMS
background is black as well.
With this commit, mpv with --vo=dmabuf-wayland can get direct scanout even if the
aspect ratio of the video and screen don't match, which can result in very significant
power savings
We optionally send some keys to xwayland through the filter when no x11
client has focus. This allows shortcut handling in X11 apps to work.
When kwin is grabbing keys we don't necessarily want X11 to sniff these
keys as things can get out of sync. A key place is the tabbox. The X11
client sill has focus, but xwayland is not active. This means we pass
tab keys to X which then go to application incorrectly.
Part of this patch changes the tabbox filter to not intercept the alt
key release event. This ensures xwayland's concept of pressed modifiers
stays in sync.
BUG: 484992
In some IM backends pre-edit text should be submitted on user interaction, in some it should be discarded.
In TextInputV1 and V2 this was a flag sent to the client along with
the commit string ahead of time.
TextInputV3 does not have a flag for this, so we handle it compositor side.
We flush the text to be committed :
- when we change keyboard focus, before the current client gets wl_keyboard.leave
- when a mouse is pressed in the relevant surface
- when a key is pressed and the InputMethod doesn't have a grab
- when the InputMethod forwards a key to the client
(which includes the InputMethod passing on grabbed keys)
