textureSize() can temporarily mismatch the target buffer size. It can be
a problem if glGetTexImage() gets called. glGetTexImage() assumes that
the provided buffer is as big as the texture. If it's not, it will write
data outside the bounds of the buffer.
BUG: 489764
pipewire 1.2 has a known regression where the client's process callback
will not be triggered if the producer has sent only one buffer.
The issue has already been fixed upstream
525360d70a
Until our CI picks up that change, temporarily disable the test to unblock
merging patches.
When disabling sticky keys while a key is latched or locked we unlatch the key, but don't tell the client until the next key event
Call forwardModifiers to tell the client immediately
We map AltGr to Qt::GroupSwitchModifier, but then ignore it
Instead map it to Mod5, which for some reason xkbcommon doesn't expose a define for
Also, since the Qt modifiers enum doesn't map nicely to XKB modifiers introduce our own enum to avoid confusion
CCBUG: 444335
It can happen that when the xwayland scale factor changes, the logical geometry
will remain the same, but the x windows still need to reconfigured to update the
native geometry.
In order to address that, this change makes X11Window track the buffer scale
so if the logical geometry is the same, the x windows will be still reconfigured
with the new xwayland scale.
X11Window::doInteractiveResizeSync() configures the x windows but it only
does a half of the things that should be done. The rest of it is assumed
to be performed by X11Window::updateServerGeometry() when XSync request is
acked later. The current state is not ideal and error prone.
This change makes X11Window::moveResizeInternal() and X11Window::doInteractiveResizeSync()
share the same code to configure the x windows to simplify the code.
It also drops X11Window::m_last{Frame,Client,Buffer}Geometry to further
simplify the code and make X window geometry tracking even more robust.
If identity transformations aren't properly optimized out, we can have additional
rounding errors and reduced performance. This test ensures that doesn't happen
After !5532 existing behavior in public scripting API was changed for maximized Windows.
Maximized Windows didn't have a tile on purpose.
This behaviour was changed, as after refactoring separate members for storing QuickTileMode in Window and tile itself were unified
Previously QuickTileMode::Maximize was only set in the Window itself in m_quickTileMode, while tile itself was removed (by setTile(nullptr)).
Current QuickTileMod for current Window isn't part of public scripting API, so it's okay to break it.
This restores compatability with scripts created for KWin 6.0.5 and earlier
BUG: 489463
Signed-off-by: Alik Aslanyan <inline0@pm.me>
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
Poll the screen cast scale from the source rather have code on top of
ScreenCastStream and ScreenCastSource that figures out by itself how the
cursor should be scaled. It ensures that the cursor size will be
consistent and it makes the ScreenCastStream initialization code simpler.
when creating a QDataStream object, if the file has not been successfully opened
before (file.open() fails), the created QDataStream object 'ds' may not function
properly. If you continue to perform the operation 'ds << icon;' in this case,
it may cause kwin to crash. Therefore, it is essential to ensure that the file
has been successfully opened before creating the QDataStream object.
Signed-off-by: likai <likai@kylinos.cn>
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
There are two shapes that the WM needs to be concerned about: the input
shape and normal shape.
If the client window has custom input shape, the window manager should
synchronize it with all parent windows or ensure that its frame window
has an input shape as big as the client's input shape. The input shape
needs to be updated either when the client changes it or when the
X11Window is resized or its borders have changed. updateInputShape()
accomplishes that.
The normal shape is slightly different. If the window is decorated, the
window manager could ignore the shape set by the client. If the window
is not decorated, it's a good idea for the WM to synchronize client's
shape with the frame window's shape (if there's any). The frame window
shape doesn't need to be updated when it's resized, but if the client
window moves inside the frame window, it needs to be updated.
This change removes too generic updateShape() in the
X11Window::moveResize() code path and replaces it with a more targeted
code to update the shape, so updateServerGeometry() does not emit the
shapeChanged signal and it can be reused in the doInteractiveResizeSync()
function. Note that on wayland, it's unnecessary to synchronize the
shapes because the client window never moves in the frame window but it
is done anyway to minimize the differences between X and Wayland sessions
for easier maintenance.
Otherwise the window might still be referenced from the opening animation, which
can lead to the effect wrongly keeping a reference to the window and staying active.
CCBUG: 485425
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)
Qt applications use Static window gravity by default. This means that if
a window decoration is created, the client window should remain at the same
position in the global coordinate space. To do that, X11Window needs to
move the frame geometry by (-borderLeft(), -borderTop()).
On the other hand, after making X11Window::framePosToClientPos() round
the window borders, the client window can end up being moved more than
expected when applying the gravity adjustment.
This change makes X11Window also round the gravity adjustment so the math
is consistent there and in the framePosToClientPos() function.
BUG: 489016
don't blindly access m_tileManagers as it can assert
with out of bounds when output is not valid. This can happen
from scripting side as this function is wrapped in the javascript api.
