With how Xwayland scaling works, KWin assumes the window already uses the
new coordinate system - but that doesn't happen until Xwayland and the client
know about the new size as well.
BUG: 480642
The failure might be from the commit reordering going wrong in some way.
The total accumulated state might still work even if an individual commit
does not though, so before considering the whole frame lost, merge all the
commits and try again
This was just done because of the wrong assumption that displays needed that
to show the full native gamut. That turned out to be an amdgpu bug though; with
that fixed, most of the 0-100% range is wildly oversaturated.
To make the slider more intuitive, this changes the sdr gamut wideness to instead
interpolate to the native display primaries as indicated by the EDID.
The screencast plugin doesn't take into account the hidden status of
the cursor, which results in the cursor being visible when screencasting
even though it's hidden.
At the moment, the desktop layout in _NET_DESKTOP_LAYOUT overwrites new
desktop layout with outdated information. This happens because kwin tries
to honor the desktop layout set by the pager. However, kwin itself
already acts as the pager. The pager applet in plasma doesn't attempt to
maintain _NET_DESKTOP_LAYOUT with proper values.
On the other hand, kwin trying to both update and also sync its state to
_NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES has created a series of
issues, like lockups or rendering glitches.
Given that the window manager can ignore these properties, and the fact
that kwin already does act like a pager, this patch makes kwin ignore
external updates to _NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES.
In order to modify the desktop layout on X11, use the dbus api. On
Wayland, either the dbus api or the virtual desktop wayland protocol.
BUG: 422319
BUG: 480371
Support is hidden by an environment variable to prevent accidental standardization
on this experimental version. It allows app devs to already implement and
test it though, and easily switch to the proper protocol later
A window is added to the workspace when it's mapped. It's assumed that
the first Window::windowShown signal indicates that. But it's not
entirely true. For example, if setHidden(false); setHidden(true); are
called in succession, the window will be marked as ready for painting
even though it isn't.
The Window::readyForPaintingChanged() signal fixes that. It's emitted
when the window is actually mapped.
At the moment, if the workspace extends or shrinks by an output, the
hidden panel will be shown. It doesn't make sense in all cases.
Furthermore, no screen edge will be reserved if the layer surface has
some margins.
To address that, allow "floating" panels reserve screen edges and also
make kwin try harder to preserve window edges if the output layout
changes.
CCBUG: 448420
It seems like QWindow::setGeometry() won't update the associated output
if no platform window has been created, which is the case when running
overview or any other qml effect.
It's not clear whether this is a Qt bug or intended behavior.
qwindow.cpp contains comments assuming that the window is on the primary
output if no platform window exists.
QQuickWindow::effectiveDevicePixelRatio() uses the device pixel ratio
of the attached QQuickRenderTarget. Instead, the scale factor of the
output should be used, which is what QWindow::devicePixelRatio() returns.
By default the focus item in a tabbox is always the main item, so if the
main item is not a focus scope, the inner item will not get focused.
BUG: 477286
FIXED-IN: 6.0
This can be used to disambiguate the exclusive edge when the anchors are
on a corner (so there would be 2 candidates)
it's quite quick and dirty mostly to understand if we do want to push for
something along the lines (it should at least do a protocol error when
the requested edge is not within the anchors)
If the active window is on a different output than the one the renderloop is for,
the scheduling logic would otherwise never schedule a repaint while adaptive sync
is active.
BUG: 480252
It's universally supported, and our format negotiation code needs improvements to
properly handle the receiving application not suporting the actual output format
